Principles of Pipelines: 14 Guidelines You Must Follow for Building Good DevOps CI/CDs.
Continuous integration
Code changes should be integrated frequently to detect and fix problems early. No 2 week long branches, I am looking at you, yes you reader. I know you do this. Merge your code darnit. Merge working, functional chunks of code whenever they are ready, you don’t need to wait to complete the whole story. Utilize feature flags and automated tests to make this possible.
Read more about Continuous Integration: https://aws.amazon.com/devops/continuous-integration/
Continuous delivery
Code changes should be delivered to production as soon as they are ready. No waiting on a release window or preplanned release cycle.
Continuous feedback
Remember that DevOps is all about Feedback loops and so are CI/CDs. Optimize the speed you collect feedback. Fail fast and fail hard. You don’t want to wait a week to find a failure when you could have found it in an hour. Organize your pipeline so the fastest feedback come first. Your linter runs very fast, make sure that runs as soon as possible in the process the devs don’t wait time. Ask yourself, what’s the fastest I can get this feedback and remember that you can run many tests locally without waiting on an external pipeline.
The CICD process should incorporate feedback loops to gather feedback on code changes and make improvements based on that feedback.
Complete Automation
This might be obvious, duh, the whole thing is automation. Think about your pipeline though, are there any manual steps other than maybe an approval button before prod deploy? If so you should work on that.
You should be able to stand and tear down full new environments in an automated fashion. This is key to moving fast safely.
Automated Testing:
You’re not waiting on a team of manual testers to work through a runbook still… right? RIGHT? Maybe you could get away with that in 2010, but this this is absolutely unacceptable in 2022. Anyone not automating their tests sufficiently is throwing money away (time is money and bugs will slip through and waist your time).
Various layers of automated tests in your CI/CD are one of the key components to CI/CD and DevOps. If you do not have this YOU ARE NOT doing DevOps.
Monitoring
The CICD process should include monitoring to detect and fix problems quickly.
Security
The CICD process should prioritize security to protect against vulnerabilities and breaches. Have you considered security while building your pipeline? There are many free security scanning tools available now such as GitHub’s automated vulnerability scans.
Scalability
All programs should be designed to grow as the user base grows, CI/CDs are no different. Who are the users of the CI/CD? The developers. Consider this while build out yours. Maybe right now while the project is small it is fine to have 1 shared environment, but what happens as complexity stacks up and devs need to move fast? Will you be able to support ephemeral environments or at least a dedicated environment per developer for their testing?
Resilience
The CICD process should be designed to handle failures and recover quickly. Can you quickly role back a bad production deploy or is it going to take an hour?
Continuous improvement
While not strictly a component of the CI/CD architecture, this is key to developing a good CI/CD. Is the team regularly discussing the good, bad, and ideas for improvement? They should be if you want to claim you are doing DevOps or being agile.
Culture
The CICD process should be supported by a culture of collaboration, experimentation, and learning.
Trunk-based development
This is a version control branching strategy in which developers work on a shared trunk branch, rather than creating separate branches for each feature or bug fix. This can simplify the CICD process and make it easier to integrate and deploy code changes.
Feature flags
Feature flags allow you to safely roll out code changes by hiding them behind a flag that can be turned on or off. This allows you to deploy code changes and test them in production before making them live to all users.
Infrastructure as code
Infrastructure as code refers to the practice of managing infrastructure (e.g., servers, networking, and security) using code, rather than manually configuring it. This allows you to automate the provisioning, configuration, and management of infrastructure, which can make it easier to deploy code changes.
Conclusion
Building a good CICD process requires a culture of collaboration, continuous learning, and experimentation. Encouraging a culture of DevOps can help to foster this kind of environment.
Are you looking to improve your AWS skills and connect with other cloud professionals?
Join the Arcadian Cloud discord group! Our community of AWS, DevOps, and full stack experts is dedicated to helping each other study for certifications, troubleshoot technical issues, enhance resumes, and secure better cloud jobs. Don’t miss out on this valuable opportunity to learn and grow with like-minded individuals. Click the link below to join now and start benefiting from the wealth of knowledge and support within our community.
Don’t forget to follow me for more updates, and smash that clap button multiple times if you like what you read 👏👏👏 — claps fuel my day and motivate me to write more awesome stuff!
