Select Page

Welcome to the first chapter on that Road To DevOps Pro! Today I went over the fundamentals of CI/CD or Continuous Integration / Continuous Delivery. The CD can also be substituted with Continuous Deployment. While they may sound similar they have fundamentally different core aspects. Here in this first post i’ll compile some of the notes I’ve taken on CI/CD.

  • Continuous Integration
    • Developers push code to a code repository very frequently
      • Example: GitHub, CodeCommit, BitBucket
    • A testing / build server verifies the code when it is pushed.
      • Examples: Jenkins, CodeBuild
    • Developer gets feedback about the tests,validations and checks that have passed or failed.
      • Integration tests, Unit Tests, Field validations
  • Continuous Delivery
    • Ensure that new features can be released reliably on demand.
    • Ensure deployments happen often and are quick.
    • Shift from “one release every sprint” to “one release a day”
    • Stems from an automated deployment process.
      • Jenkins, CodeDeploy, Spinnaker
  • Continuous Delivery vs Continuous Deployment
    • Continuous Delivery
      • Ability to deploy often using automation
      • May involve a manual step to “approve” a deployment.
        • Common practice is to have staging environment as close to production as possible. Then code can be quickly approved and deployed to production.
      • Deployment itself is still automated and repeatable.
    • Continuous Deployment
      • Full automation, all code updates that pass the automated tests are deployed to production.
      • Approvals and manual interventions are not needed.
  • Technology Stack for CICD in AWS
    • Coding – AWS CodeCommit / GitHub
    • Build/Test – AWS CodeBuild / Jenkins
    • Deploy/Provision – AWS CodeDeploy / AWS Elastic Beanstalk / AWS CloudFormation
    • Orchestration Tool: CodePipeline, Jenkins

CI/CD Best Practices

  • Make small and frequent deployments.
  • Minimize branching and make CI/CD pipeline the only method of deploying to production.
  • Run tests locally before committing to the pipeline.
  • Automate your build testing.
  • Fix broken builds as soon as possible.

In the next part of my series I’ll be giving a brief overview of the important of source/version control. I’ll also give give my thoughts on AWS CodeCommit as a source control service. So look forward to it.