It wasn’t so long ago that software teams wrote code for months, or even years at a time before delivering to the customer. Teams deployed huge monolithic applications all at once. This approach translated into a lot of planning, a lot of QA, and a lot of stress, and it obviously has some downsides. With Continuous Integration and Continuous Delivery (CI/CD), slow, frustrating development practices are becoming a thing of the past.
CI/CD aims to solve some of the problems associated with traditional Waterfall development by breaking the process into smaller, more nimble workflows, saving you work and increasing the pace of code integration.
Continuous Integration
Traditionally, many development teams worked on changes in isolation, then handed them off to a separate team for integration into the main codebase. This was a tiresome, time-consuming process often called “integration hell”.
Continuous Integration is a process that ensures new code is merged to the main codebase quickly and easily. Using a good branching strategy, you make sure not just any code gets into your main branch. The development team can be responsible for new development as well as integration into the main codebase.
When work is finished, it is committed to a repository which triggers a job in your CI/CD tool. The job tries to build the code and runs any automated tests. Any additional steps, such as restoring packages, are also done in this step.
If a build fails, for whatever reason, the team gets notified that the build just broke. After receiving a notification, it is important to fix the code as soon as possible.
If all is well and the code builds and tests correctly, it can be integrated into the main codebase right away. Fast integration keeps development velocity up and means the codebase is always in a healthy and up to date state. If done well, development teams never have to worry about their main codebase being in an unreleasable state. Any issues are found quickly and can be addressed quickly. Everyone should be doing CI!
When your main codebase is always healthy it’s easy to create a release package, which can be made into an artifact. Your CI/CD tool can then release the artifact later on, taking us to Continuous Delivery.
Continuous Delivery
Continuous Delivery is the practice of always being able to deploy your code. In the best case scenario, CD deploys code without any human intervention other than telling your CI/CD tool to run a deployment with a simple button click.
Taking things a step further is Continuous Deployment, which means code is automatically deployed when your main branch passes all builds, tests and approvals. This is often done for development and test environments, while still practicing continuous delivery for deployments to production.
Unfortunately, things are never that easy. Infrastructure is often hard to completely automate. There are various tools for on-premises environments while cloud environments usually work with scripts to create resources. Often, a system admin manually installs the entire infrastructure. The CI/CD tool then deploys every software update automatically.
So the difference between Continuous Delivery and Continuous Deployment is that with delivery, the business decides when to deploy code to production, while with deployment this is done continually. Both are valid options, and it’s up to your business to decide what works best.
Ossum and CI/CD
Ossum does not include built-in tools to handle automated builds or deployments. Ossum does integrate very well with the CI/CD tools you’re probably already using. Currently, Ossum supports integration with Jenkins, Bamboo, and TeamCity.
Ossum supports merge requests and code reviews, which are paramount in your CI process. Whenever you push code to ossum, it can trigger a test and build job with your CI software and report the results back. Ossum greatly helps in setting up your CI/CD process.
What’s really great is that you get the build status on card level on the Kanban board.
Another great feature is that you can have different builds for merge requests and the actual merges. And if the build for the merge request succeeds, your request automatically gets a thumbs up.
Conclusion
The aim of CI/CD is to reduce manual steps during a deployment. This makes it easy for any member of the team to do a deployment. If your automated builds and tests are reliable, it should be possible to deploy at any time. Ossum helps in visualizing which code and tasks have been built, which failed, or which were released. Try it today with a free ossum trial.
If you’re interested in developing expert technical content that performs, let’s have a conversation today.
