The “Continuous” Development Methodology
As we move towards distributed architectures that are composed of many sub-systems, one aspect that is true for every system is that you will be making a lot of deployments. More machines mean more things you need to deploy to.
Thankfully our industry has matured enough, and many have adopted various practices to answer these problems, which you might have heard of as Continuous Integration, Continuous Delivery, Continuous Deployment, or Continuous Verification. I’ll be going over how these practices can improve your software development experiences and build more robust systems.
Continuous integration begins at the developer level, where the expectation is that developers will try to check in their changes as often as feasible. Developer check ins should be validated in some fashion through testing (unit and/or integration), before they can be validated as proper builds. These builds are then pushed to your Test environment frequently to see how it behaves against the rest of the system.
Why is this important for developers:
- They can see potentially bugs and design issues earlier in the development process
- Smaller changes are easier to pinpoint issues, leading to less debugging time
Continuous delivery is the practice of automating your build and release process so that it is safe and easy to deploy to production environments. This can be achieved through various platforms, such as Jenkins, Team Foundation Server, Travis CI, and many more.
Being able to automate your build and release is a very powerful tool that gives you the ability to make releases quickly. Building release candidates can take precious time away from your key developers, where they can be building the business value you need.
This practice does not specify any specific guidance around when your organization does their releases, but only asserts that the process be available to prepare production releases through an automated process.
This step usually requires more involvement from your organization, to them to buy in and allocate resources to building this infrastructure, and tools around it.
Continuous deployment takes the ideas of continuous delivery a step further by asserting that any change set that passes the validation process / pipeline will be automatically released to production.
This is approach would have the fastest feedback from users, but also carries risk if your validation process is not thorough enough.
This step would take immense buy in from your organization, especially more so from the product side as they have less control of when features are released.
Continuous verification is the post-release practice of automating the monitoring of your system to determine the validity of your release, and give you metrics for determining if your release was a success, or if it should be rolled back. This can be done through a variety of ways: checking overall rate of response status, comparing response results to previous ones, checking server health and environment statistics.
You can integrate this as part of your canary release, by making it part of the approval step for full-release.
Putting it All Together
- Automate your builds — Save developer time
- Automate your tests — Add confidence to each build
- Automate your deployments — Add agility to your deployments
- Automate your verification — Deploy with confidence
“Continuous” development is the methodology of automating your build and release processes.
As a developer,
You want to want to integrate your code as early as possible to find bugs and design flaws early. You want to push code frequently as well, but be able to have confidence that you aren’t breaking your system by verifying it with automated testing. You want to have your build process automated so that you can push changes on demand to production. You want to be able to know how that your changes are working in production, where it matters the most.
As an organization,
You want to have incremental changes that allow you to solicit feedback early in the process so that you can make more effective decisions for your product. You want to introduce changes slowly into the environment to reduce the risk of large integration failures.
“Continuous” development can take a large investment from both the developers and their organization, but the stakes of IT organizations have been ever expanding as systems become larger and more complex. If your organization does not take advantages of this methodology, you should look to see what parts may benefit your organization. You don’t have to take all of these steps at once, and not all systems would benefit from doing so. It would be wise to investigate which parts of the process would help your team and try incorporate one part at a time and see if it fits your needs. Continuous development practices and principles are a staple in the modern development life cycle, and has been battle tested to bring agility and confidence to each of your releases.
References and Further Reading:
- Continuous Integration, ThoughtWorks
- Continuous Integration vs Continuous Delivery vs Continuous Deployment, Sten Pittet — Atlassian