CI/CD

Notes on the standard devops practices of enabling your team to continuously integrate and deliver your product

Continuous Integration

Processes and tools that allow for continuously integrating and testing new code prior to and after merging into your master branch
Goal is to build confidence when merging changes from different branches into your master prior to deploying code to production
Basic setup looks like this:
- Accepted, solid git branching model in place
- Robust automated test suite written and up-to-date
- Task-running tool(s) like Jenkins, GitHub Actions, and/or CircleCI that run all tests on merge into master validating code functionality and catching bugs before deployment
  - Even better setup is to run all tests on PR creation for the given branch, and then all tests on master once merged in

Automatic deployment of most recent code changes to a staging environment
- Staging environment should be as similar to your production environment as possible for maximum confidence in regression testing
Leverages same task-running tools as CI processes for this
Having a green / successful build in your CI tools doesn’t guarantee that your code is production-ready; testing in a production-like environment adds to the confidence that it actually is ready
Deployments to production are still a manual step
- Should be a super easy manual step, i.e., a single push of a button; but it’s not automatically pushed out

Next evolution of Continuous Delivery: All code that passes automated tests is automatically deployed to production
Some companies shouldn’t strive for Continuous Deployment due to regulatory restraints on their given industries
- They can / should implement Continuous Delivery, though
- If you’re not bound by regulatory issues, you should strive for Continuous Delivery