Continuous integration (CI) is the process of automatically building and testing your software on a regular basis. How regularly this occurs varies. In the early days of agile, this meant daily builds, nowadays, this can be as often as every commit. That means running a full suite of unit and integration tests against every commit
Continuous delivery is an approach where teams release quality products frequently and predictably from source code repository to production in an automated fashion.
A continuous delivery pipeline could have a manual gate right before production. A manual gate requires human intervention, and there could be scenarios in your organization that require manual gates in pipelines. Some manual gates might be questionable, whereas some could be legitimate. One legitimate scenario allows the business team to make a last-minute release decision. The engineering team keeps a shippable version of the product ready after every sprint, and the business team makes the final call to release the product to all customers, or a cross-section of the population, or perhaps to people who live in a certain geographical location.
A monolithic product architecture can result in a big ball of tests. I’d recommend investing into microservices such that independently deployable artifacts can flow through pipelines without needing a highly integrated environment for certification. Also, independently deployable artifacts enable faster teams to not get bogged down by slower teams.
The software delivery pipeline is a product in its own right, and is a priority for business, otherwise we should not send our revenue-generating products through it.
Velocity means responsible speed, not suicidal speed. Pipelines are meant to ship quality products to our customers. Unless teams are disciplined, pipelines can shoot faulty code to Production, only faster! Automated software delivery pipelines help organizations respond to market changes better.
A spike in productivity results when tedious tasks, like submitting a change request for every change that goes to Production, can be performed by pipelines instead of humans. This lets scrum teams focus on products that amaze the world, instead of draining their energy on logistics. And that can make team members happier, more engaged in their work, and want to stay on the team longer.
Sustainability is key for all businesses, not just tech. “Software is eating the world” is no longer true — software has already consumed the world! Every company at the end of the day, whether in healthcare, finance, retail, or some other domain, uses technology to differentiate, and to outmaneuver their competition. Automation helps reduce/eliminate manual tasks that are error-prone and repetitive, thus positioning the business to innovate better and faster to meet their customers' needs.
Compiling code should only happen once, eliminating the risk of introducing difference due to environments, third party libraries, different compilation contexts, and configuration differences.
Use the same automated release mechanism for each environment, making sure the deployment process itself is not a source of potential issues. While you deploy many times to lower environments (integration, QA, etc.) and fewer times to higher environments (pre-production and production), you can't afford failing deployment to production because of the least tested deployment process.
A non-exhaustive software test (essentially testing "everything" – services, database, messaging bus, external services, etc.) that doesn’t bother with finer details but ascertains that the most crucial functions of a program work, will give you the confidence that your application actually runs and passes basic diagnostics.
Create a production-like or pre-production environment, identical to production, to validate changes before pushing them to production. This will eliminate mismatches and last minute surprises. A copy of production should be as close to production as possible with regards to infrastructure, operating system, databases, patches, network topology, firewalls, and configuration.
The first stage should be triggered upon every check-in, and each stage should trigger the next one immediately upon successful completion. If you build code hourly, acceptance tests nightly, and load tests over the weekend, you will prevent the achievement of an efficient process and a reliable feedback loop.
When a stage in the pipeline fails, you should automatically stop the process. Fix whatever broke, and start again from scratch before doing anything else.
When is a good time to adopt continuous delivery? It was yesterday.
Continuous delivery is the right thing to do, and occasionally require champions to jumpstart the transformation. Eventually, when designed right, continuous delivery pipelines pay for themselves and organizations, on hindsight, are glad they decided to bite the bullet.
So, who is involved?
Some organizations put inexperienced people to design and implement continuous delivery pipelines, and learnt the hard way that there were deep intricacies involved. Appointing junior members sends the wrong signal to teams, and implies that continuous delivery has a low priority. I strongly recommend putting a senior architect in charge, who has a deep appreciation for technology and business.
Do not forget Conway’s Law when designing software architecture and CI/CD pipelines
There’s a quite a lot of CI/CD tools available these days. Most of them overlap heavily. Your team is probably comfortable using GitLab/GitHub/Bitbucket.
Next input is where you run your app? On-prem, public or private cloud? Are there any integrations with my platform?
Choose the CI/CD system that integrates well with your current stack. Do you want a simple Pipeline as a Service or rather build your own?For end-to-end Pipeline as a Service check out Shippable if you are using GitHub.For Google Cloud Platform check out Google Cloud Build.
If you want to build your pipeline platform, definitely try Jenkins (with Pipeline plugin) and for more complex CD - add Spinnaker to Jenkins. See, that’s the cool thing about this tooling, you can combine multiple tools in your pipeline!
If your team is a heavy user of Gitlab, check out Gitlab-CI.
Irrespective of where we are in our journey of continuous everything (integration | testing | delivery | deployment | analytics), it is neither a checklist nor a destination, and continuous improvement is at the heart of it.
Sooner or later, everyone in the organization gets a call when continuous delivery pipelines are being constructed. Executives, Engineering, Product Management, Governance, Risk, Compliance, InfoSec, Operations, Legal and whatever you have. Pipelines gnaw through silos and break down walls. All of us are part of this transformation, one way or the other, and continuous everyone is the new normal!
Sources: https://www.atlassian.com/continuous-delivery
.