CI/CD is a common term nowadays in the tech world and not everyone might be familiar with it, So what is it?
Phases of CI/CD Pipeline
Key Terms
CI/CD is a software development process that automates the deployment of software.
Continuous Integration (CI) is a practice of merging all developers working copies to a shared mainline repository, this can happen multiple times per day.
Continuous Delivery (CD) is an engineering practice in which teams produce and release value in short cycles.
Continuous Deployment (CD) is a software engineering approach in which the value is delivered frequently through automated deployments.
Pipeline is a set of data processing elements connected in a series to form a continuous flow of data.
Infrastructure as Code is the management of infrastructure using code.
Testing is the process of validating the quality of the software.
DevOps is a set of practices that works to automate and integrate processes between software development and IT teams.
Provisioning is the process of setting up IT infrastructure.
Best Practices for CI/CD
- Fail fast - set up your CI/CD pipeline to find and reveal failures as early as possible. The faster you find the failure, the faster you can fix it.
- Measure quality - measure your code quality and test coverage before you deploy.
- Only road to production - since CI/CD does deployment on your behalf, it must be the only way to deploy and get rid of any manual steps.
- Maximum automation - if it is a process that can be automated, automate it
- Config in Code - all configuration code must be in code and versioned alongside production code. This includes CI/CD configuration, and deployment scripts.
8 Principles of Continuous Delivery
- Repeatable reliable process
- Automate everything
- Version control everything
- Bring the pain forward
- Build-in quality
- “Done” means released
- Everyone is responsible
- Continuous improvement
Deployment Strategy
- Big Bang - Replace A with B all at once, A is the new version and B is the previous version.
- Blue-Green - Two versions run at the same time, blue is the previous version and green is the new version. The traffic can still be routed to blue while testing green and shifting to green when green is ready.
- Canary - This is also known as the rolling update, after deploying anew version traffic gets started being routed to the new version bit by bit until all the traffic hits the new version. Both versions will coexist for a period of time.
- A/B Testing - Similar to canary, but instead of routing traffic to new version, you test your new version with a subset of users in order to get feedback, then later route all traffic to the new version.
| Big Bang Pros | Big Bang Cons |
|---|---|
| Simplest to understand and perform | Downtime while you are replacing A with B |
| Encourages teams to batch up changes into large deploy event | |
| Requires more testing and cordination | |
| Features go to market very slowly |
| Blue Green Pros | Blue Green Cons |
|---|---|
| Allows you to test new production deployment without disturbing the old one | More costly infrastructure with two production servers running. |
| If it doesn’t work you can do a fast rollback |
| Canary Pros | Canary Cons |
|---|---|
| If there is a problem you can stop the roll out and in turn only a small portion of users will be affected | More costly tham big bang since you will have two production servers running for a period of time. |
| Quite a bit more difficult to set up |
| A/B Testing Pros | A/B Testing Cons |
|---|---|
| Get feedback from users on new version | Potential costly method of user acceptance testing |
| More difficult to set up than canary |
Pipeline Building Blocks
- Build - this involves everything that has to do with making code executable in production.
- Test - this involves everything that has to do with testing the code and making sure it is working correctly.
- Analyze - this involves static analysis on the code or checking of dependencies.
- Deploy - this involves everything that has to do with creating server instances or copying pre-built application files to instance.
- Verify - this involves any test that can be run against the deployed application.
- Promote - this involves replacing the current production environment with the new version which was deployed
- Rollback - this involves rolling back changes in case any verification fails after deployment.
Characteristics of a Healthy CI Pipeline
- Highest priority when build is broken
- Trusted members of the team
- Have the same abilities as any member of the team
- Enforce team quality rules
- Communicate useful information
- Shorten feedback loops
- Don’t require stacks of documentation
- Automated to the end
Top comments (0)