“Test early, test often”. This old software development principle applies to many areas beyond just testing. Fact is, if you do something frequently, you will get better at it, even if you don’t aim to become an “expert”.
Traditionally software has been developed in a waterfall model, where each phase of the process follows the next phase in a sequential manner. Towards the end of this process you will find some type of deployment or release, a really painful deployment or release. Why? Because the release happens about once a year.
By adopting agile development methodologies, teams started to reduce this release cycle by implementing iterative and incremental development practices. Deployments become shorter with teams often deploying new versions of their software every 2 to 6 weeks. Remember, the more you deploy the better you will get at it. Even if you do it every 2 weeks, you are probably still happy with the deployment process having a number of manual steps and taking a couple of hours, but what if you have to **deploy 20 times a day**? Enter Continuous Deployment, the hallmark feature of Bamboo 3.0, which we announced today.
Continuous Deployment doesn’t necessarily mean that every commit is being released into production. Depending on your industry or the product you create this is often not feasible. Also, as a product manager, I would argue that continuous updates to a product can lead to a bad customer experience depending on the audience and the type of changes. However, there are many ways teams can benefit from Continuous Deployment.
At Atlassian we have been working on a new Editor for Confluence 4. Full WYSIWYG with a completely new XHTML backend. Now you can imagine that this is a huge change to the core of the product. Confluence also powers our Intranet, usually running the latest milestone of Confluence to help with “dog-fooding” the release… except we are not running Confluence 4. Why are you not run Confluence 4 you may ask? Because it takes us too long to deploy a new version if a critical bug is detected. And with our Intranet being core to our business, we cannot afford to wait 2 hours until a new version of Confluence with a bug-fix can be deployed. But Continuous Deployment helps us to solve this issue by automating every step from checking in code to running it in production.
A feature is being committed and triggers a build. The build can either be triggered automatically, or if you want more control over it, you can schedule builds for specific times.
The Build runs through a number of Stages:
- Compile — this is specific to Java and other compiled languages, but generally is the phase where you prepare your app.
- Unit Test — they are fast, so run them first. If something breaks here, there is no need to move on to the next stage.
- Acceptance Test — We are using automatic tests via JUnit. To speed up the tests, we’ve created a number of batches and run them in parallel.
- Selenium Test — We run Selenium tests against a number of environments at the same time.
- Deployment — The deployment to UAT happens automatically after all tests have passed.
We choose to do some additional manual testing of new features before we release into production. The QA team can check out the build and see associated JIRA tickets to know what to test. A test deployment also allows us to catch any major issues by monitoring the service and look for abnormalities.
Deployment to Production
If QA is happy with the build, we can push a button and trigger the next deployment, using the same artifact that we’ve created, tested and pushed to the UAT environment beforehand. The process of deploying to a live system (although in our case it’s not actually released to customers), is completely automated, apart from a single push-button deployment. If we get confident enough in the future, we might even remove this requirement and completely automate the whole process, but you want to make sure that you have the right monitoring systems in place that can trigger alerts as soon as the system loads or other metrics seem unusual.
Let’s not kid ourselves, Continuous Deployment certainly requires a good amount of discipline to prevent regressions or bugs. But as “Eric Ries”: pointed out, it’s enough to follow “5 simple steps”: to implement Continuous Deployment. And there are a heap of benefits that you can get out of adopting Continuous Deployment. In our case, the biggest benefit is that we can run and test the latest version of Confluence way before we actually release it, leading to an overall better quality product. We find bugs and regressions much earlier, and since the changes are generally small, it is a lot easier to fix them. And when we get to the release, instead of taking up a whole afternoon of a developers time, it will be just a button click away!