How We Integrate Testomato into Continuous Delivery
In recent years, the most commonly used development method has been shifting from more traditional models like waterfall to a more iterative model: agile software development.
Agile development processes often use continuous delivery or continuous deployment, and automated testing is essential part of any of these processes in order to keep iterations as fast as possible.
Testomato can be easily integrated into your existing deployment process, regardless of what set up your team is using.
We’ve talked about how we use a mix of agile techniques to develop Testomato before on our blog. In this post, we wanted to share how we integrate Testomato into our development process.
We believe in using our product as much as possible in the hopes of learning more about ways we can improve. After all, who better to use Testomato than the team who made it!
A Closer Look at Continuous Delivery v.s. Continuous Deployment
There’s some confusion over the differences between continuous delivery and continuous deployment. We can’t cover it fully today, but here are the basics.
Continuous Delivery is an approach where you use practices to ensure software is releasable at any point in its lifecycle.
Continuous Deployment means that every change goes through your development pipeline and is then automatically pushed to production, meaning you should have several deployments a day.
Crisp’s Blog made a great visual summarizing ThoughtWorker Jez Humble’s original 2010 post on the topic of continuous delivery v.s. continuous deployment.
Here it is:
Basically, continuous delivery keeps the step of releasing to production as a manual step while continuous deployment deploys to production immediately after verification.
Continuous deployment isn’t practical for everyone – some businesses need to wait for a feature to go live.
That being said, continuous delivery is great way to reliably deliver value to your end users and relieve your own stress over releases.
How We Work
The main principle behind Continuous Delivery is to build in a way that allows you to release your application to production at any time.
This means that in theory we should always have the latest possible version of Testomato on our servers. We don’t plan milestone releases like a version upgrade.
Instead, we continuously integrate our changes to a production-like environment (staging), where they undergo automated testing to make sure they function as expected.
Once we feel those changes are ready, they are deployed to production.
Here’s a basic overview of how our process works:
- Developers build in their own development environments.
- Changes are pushed to our staging or pre-release environment whenever they are ready.
- Staging environment undergoes automated testing from both Testomato and Selenium.
- Manually controlled release to production.
- A one hour period of testing on production using both Testomato and Selenium.
- Regular automated testing of production using Testomato, which is shown on two screens throughout our offices.
Why Automated Testing Should Be Part of Your Process
Setting up automated testing in a staging environment is meant to flush out any problems that may occur in production. By testing in controlled conditions, which mimic your production environment as closely as possible, you won’t run the risk of as many problems.
Additionally, any time someone makes a change in your system, you’ll be able to get fast, automated feedback on whether or not you’re ready to push to production.
In regards to our team, we use both Selenium and Testomato to help us conduct our application acceptance tests in both environments. These tests make releases more relaxing, which helps us deliver changes more frequently to our users.
It’s easy to integrate Testomato into any process for any size team. Please feel free to share your thoughts with us!
Leave us a comment below or on Facebook. You can also tweet us directly @testomatocom.
