Integration Deployment Software | 2017-10-10
Continuous Integration and Continuous Deployment
What is it and why is it valuable for the business?
Continuous Integration is a practice that encourages developers to integrate their code into a main branch of a shared repository early and often. Integrating code frequently doesn’t guarantee quality code or functionality. Robust test suites and an automated system to run those tests. When a developer merges code into the main repository, automated processes kick off a build of the new code. Afterward, test suites run against the new build to check if any integration problems were introduced.
Continuous Depoloyment helps automatically deploy each build that passes the full tests. Deploying automatically pushes features or fixes to customers quickly. With this model there isn’t a final manual verification for the code being deployed, so developers must take responsibility that their code is well-written and test cases are up-to-date. There are several ideas around Continuous Delivery
- Continuous Deployement aka - Continuous Release
- It has to deal with Agile development
- Extension of Continuous Integration
Personally, I don’t believe any of them. Parts, yes. But not all. For some projects continuous delivery (to users) doesn’t apply. Continuous delivery assumes that every delivery that is QA’d should become directly available to users immedietely. Releases are generally strategic or political and it’s hard to assume that everyone wants to do this. Some companies like financial services can not deploy during the day without a large effort and documentation why it’s needed. Others, prefer for when users are mostly offline and require QA and Developers to be online. But there are some businesses that can release at any point and it doesn’t impact the end users experience or could detriment the company. Examples of this would be un-launched software that you’re integrating with an external team for, blog’s because they have little to no traffic and the experience doesn’t matter
There are also a ton of products that help this, but many don't address the business or strategic concerns to come allong with building software.
Production releases have risks and the business should know about potential woes:
- Having to refresh servers because static code was not refreshed
- Functionality wasn’t as expected and business needs to know how it impacts users
- Build tools or secondary servers go down randomly when we want to release
Wait. What? Is that all CI and CD are?
Yes, they are a million dollar terms and most teams do it without thinking about it too much. It works well if you get it right and it’s flexible enough that if it’s not working you can change the build settings so it doesn’t take a lot of time out of your day.