CI/CD is often visualized as a pipeline. A more apt analogy would be a manufacturing process; where new code is submitted on one end, tested over a series of stages (source, build, staging, and production), and then published as production-ready code. Within this process we have requirements, raw materials (code), functionality (compiled code), testing, quality assurance and delivery.
The pre-requisites for CI-CD are the following and given that the process is complex and costly, firms should make certain that they truly need an automated CI-CD approach: long-lived products; digital clients and demands; changing functionality; many versions; a clear business owner and plan; the product is revenue creating or client-facing (enabling an ROI to be developed).
CI-CD is akin to manufacturing a car. The line, processes, tools, part and approach are standardized. As the car rolls down the line it is built, tested, assessed for quality at each station. If a car is found defective at any station the line is stopped and a resolution is made. Software is no different.
To get familiar with the manufacturing of software via CI-CD start small. Take one team, set up standards, tools, processes, documentation, Agile-Scrum (roles, processes, culture, training), and iterate at each stage so that you can understand and develop your code in a manner that reflects your firm (every firm will usually have a different approach). Successful firms invest in training, a Center of Excellence, and have a clear Business and IT rationale as to why they need CI-CD.
Figure: CI/CD pipeline
As with manufacturing each stage of the CI/CD pipeline is structured as a logical unit in the delivery process.
Every stage acts as a ‘gate’ that filters and allows code deployment. As the code progresses through the pipeline, the assumption is that the quality of the code is higher in the later stages because more aspects of it continue to be verified. Problems uncovered in an early stage stop the code from progressing through the pipeline. Results from the tests are immediately sent to the team, and all further builds and releases are stopped if software does not pass the stage.
The presence of a CI/CD pipeline will have a large impact on maturing the capabilities of the IT group. The organization should start with small steps and not try to build a fully mature pipeline, with multiple environments, many testing phases, and automation in all stages at the start. Keep in mind that even organizations that have highly mature CI/CD environments still need to continuously improve their pipelines.
Figure : Continuous integration—how it works
The first aspect of CI/CD is integration. All developers should regularly commit their code to a central repository (such as one hosted in CodeCommit or GitHub) and merge all changes to a release branch for the application. No developer should be holding code in isolation. If a feature branch is needed for a certain period of time, it should be kept up to date by merging from upstream as often as possible.
Frequent commits and merges with complete units of work are recommended for the team to develop discipline and are encouraged by the process. A developer who merges code early and often will likely have fewer integration issues down the road.
Developers also need to use code-unit tests as early as possible for their applications and to run these tests before pushing the code to the central repository. Errors caught early in the software development process are the cheapest and easiest to fix.
When code is pushed to a branch in a source code repository, a workflow engine monitoring that branch will send a command to a builder tool to build the code and run the unit tests in a controlled environment. The build process should be sized appropriately to handle all activities, including pushes and tests that might happen during the commit stage, for fast feedback.
Other quality checks, such as unit test coverage, style check, and static analysis, can happen at this stage as well. Finally, the builder tool creates one or more binary builds and other artifacts, like images, stylesheets, and documents, for the application.
Continuous Delivery: Creating Test-Stage-Prod Environments
The 3 environments should be exactly the same. CD entails deploying the application code from test-dev into a staging environment, which is a replica of the production stack, and running more functional tests. The staging environment could be a static environment premade for testing, or you could provision and configure a dynamic environment with committed infrastructure and configuration code for testing and deploying the application code.
After the staging environment is built using infrastructure as code (IaC), a production environment can be built very quickly in the same way.
The final phase in the CI/CD pipeline is continuous deployment, which may include full automation of the entire software release process including deployment to the production environment. In a fully mature CI/CD environment, the path to the production environment is fully automated, which allows code to be deployed with high confidence.
==END