It's important to note that
DerekContinuous DeliveryandContinuous Deploymentare not the same thing. The two get conflated and sometimes used wrong interchangeably.Continuous Deploymentspecifically means deploying straight to production.
When CI/CD is put into practice it creates automation. When automation works as it is intended, it's magical.
What is Continuous Integration and why do we need it?
Continuous integration, also known as "CI" is a development practice that requires developers to integrate code into a shared repository several times a day.
In the image above, two users are developing on a common project. When they are done, they will use git to check in their code to the source repository on github or bitbucket.
Each check-in is then verified by an automated build, allowing teams to detect problems early. The CI server will build, test, and produce results which can then be seen by the team.
If the build fails, it's referred to as being "Red" - the developer will be notified immediately and be able to identify the particular snippet of code and resolve the issue.
If the build is "Green" (successful), then there is no compilation errors and the code is good to progress.
This allows us to spend significantly less time tracking down errors or discovering where things went wrong.
Key take aways:
- Spend less time debugging and more time adding features
- Stop waiting to find out if the code you wrote will work
- Reduces integration problems allowing you to deliver software more rapidly
I've heard people call Continuous integration cheap, what does that mean?
You may hear people refer to CI being cheap. What they mean by this is that if you follow a continuous integration approach, you'll have shorter periods between integrations. Longer periods between integrations is something we want to avoid because there are more changes and obviously more difficult to track down and fix the issues.
Imagine for a moment that 5 teams are independently working on projects and go long periods between integrations. When they do integrate, they will be spending a lot of time tracking down problems, fixing them, and running the clock costing more money. Developers aren't cheap.
How do we implement continuous integration?
Continuous Integration is backed by several important principles and practices.
The key practices we need to consider are:
- Maintain a single source repository
- Automate the build process
- Create self-testing.
- We will want to make it easy for anyone to get the latest executable version
- Access so everyone can see whats happening.
- We will need to automate deployment
How do we do this?
Developers will need to check out code into their own workspaces and then when they are done they will need to commit the changes to the repository at regular intervals.
Next, we will need to set up a CI server that will monitor the repository for changes to trigger builds and tests when a commit occurs.
The CI server will then build the system and run unit and integration tests. It will then release deployable artifacts for testing and label the build (called a build label) to the version of code that was run. The team will then be informed of the status of the build - Green or Red (sucess/fail). If the status is red, the team will be alerted and the team will resolve the issue at the earliest opportunity.
Teams responsibilities:
As a team member of an organization, it's important not to check in code that is broken - if you do, it will block builds from your team until it is resolved. You do want to check in your code as frequently as possible to identify problems early though.
Don't check in untested code. You can run the integration test or unit test before checking it in.
Don't check in when the build is currently broken (red) - that may create another issue where the root cause of the failure is resolved but still red because of a bug in the code you are checking in.
We will use Jenkins to perform all of these tasks as our "CI server".
What is Continuous Delivery?
Continuous Delivery, also known as "CD" Continual delivery of code to an environment once the code is ready to ship. Essentially, it is the practice of releasing every good (green) build to end users. This process helps ensure the deployment of new features into production as soon as it's ready.
By adopting both Continuous Integration and Continuous deployment, also known as a "CI/CD pipeline", you not only reduce risks and catch bugs quickly, but also ship new features quickly to your customers!
Next...
In my next article we will look at Jenkins. If you found this article helpful, give me a shout on twitter @codingwithdrewk or if you find any errors, feel free to highlight them and mash that R button the right side of the screen.
Terms and definitions:
Artifact: Any description of a process used to create a piece of software that can be referred to, including diagrams, user requirements, and UML models.
Continuous Integration (CI): the practice of merging all developers' working copies to a shared repository several times a day.
Continuous Delivery (CD): Continual delivery of code to an environment once the code is ready to ship
Drew is a seasoned DevOps Engineer with a rich background that spans multiple industries and technologies. With foundational training as a Nuclear Engineer in the US Navy, Drew brings a meticulous approach to operational efficiency and reliability. His expertise lies in cloud migration strategies, CI/CD automation, and Kubernetes orchestration. Known for a keen focus on facts and correctness, Drew is proficient in a range of programming languages including Bash and JavaScript. His diverse experiences, from serving in the military to working in the corporate world, have equipped him with a comprehensive worldview and a knack for creative problem-solving. Drew advocates for streamlined, fact-based approaches in both code and business, making him a reliable authority in the tech industry.