AWS DevOps Pro Domain 1: SDLC Automation (part 1)

By | September 19, 2021

In this series of articles, I’m going to go through Domain 1 of the AWS Certified DevOps Engineer Professional exam guide. As such, I will break down each of the concepts into walk-throughs of the process:

  • 1.1 Apply concepts required to automate a CI/CD pipeline
    • Set up repositories
    • Set up build services
    • Integrate automated testing (e.g., unit tests, integrity tests)
    • Set up deployment products/services
    • Orchestrate multiple pipeline stages
  • 1.2 Determine source control strategies and how to implement them
    • Determine a workflow for integrating code changes from multiple contributors
    • Assess security requirements and recommend code repository access design
    • Reconcile running application versions to repository versions (tags)
    • Differentiate different source control types
  • 1.3 Apply concepts required to automate and integrate testing
    • Run integration tests as part of code merge process
    • Run load/stress testing and benchmark applications at scale
    • Measure application health based on application exit codes (robust Health Check)
    • Automate unit tests to check pass/fail, code coverage
      • CodePipeline, CodeBuild, etc.
    • Integrate tests with pipeline
  • 1.4 Apply concepts required to build and manage artifacts securely
    • Distinguish storage options based on artifacts security classification
    • Translate application requirements into Operating System and package configuration (build specs)
    • Determine the code/environment dependencies and required resources
      • Example: CodeDeploy AppSpec, CodeBuild buildspec
    • Run a code build process
  • 1.5 Determine deployment/delivery strategies (e.g., A/B, Blue/green, Canary, Red/black) and how to implement them using AWS services
    • Determine the correct delivery strategy based on business needs
    • Critique existing deployment strategies and suggest improvements
    • Recommend DNS/routing strategies (e.g., Route 53, ELB, ALB, load balancer) based on business continuity goals
    • Verify deployment success/failure and automate rollbacks

CI/CD Overview

  • Continuous Integration = testing code when a developer submits code to a repository (repo) like CodeCommit. This is the practice of automating the integration of code changes (usually from multiple contributors) into a single project or repo. Developer gets quick feedback from testing on if checks pass/fail. Finds & fixes bugs quickly.
    • CodeCommit / Github for repo
    • CodeBuild / Jenkins CI for testing / build server
  • Continuous Delivery = Deliver software/updates to production in smaller increments. Ensures software can be reliably released at any time. Usually involves a manual authorization step before deploying to production.
    • CodeDeploy
    • Jenkins CD
  • Continuous Deployment = Automated end to end. Code change is pushed to repo –> testing –> deployed to production
    • No manual intervention of approvals

CodeCommit overview

  • private Git repo
    • no size limits
    • HA
    • Code only in AWS account
    • Integrates w/ Jenkins / CodeBuild / other CI tools
    • Topics to understand:
      • Basic Git commands (status, add, commit, push, checkout, etc…)
      • Branching -> used for new features/environments & code changes
      • How Pull Requests work
      • use IAM policies to secure master branch
      • Notifications & Triggers (used for automation of repository tasks):
Notification Events

CodeBuild Overview

  • Fully managed build service (like Jenkins)
    • No servers to provision – no build queue
    • Only pay for the time it takes to complete a build
    • Uses Docker under the hood
    • Can extend functionality using own Docker base images
    • Security:
      • Integrates with KMS for encryption of artifacts
      • IAM for build permissions
      • CloudTrail for logging API calls
      • VPCs for network security
    • Source code can come from many sources (CodeCommit, GitHub, CodePipeline, etc…)
      • Reference Type = Branch, Git tag, or Commit ID
      • If you want to test multiple branches, you need multiple CodeBuild projects
    • buildspec.yml A buildspec is a collection of build commands and related settings (in YAML) that CodeBuild uses to run a build. Can be included as part of the source code or can be defined when you create a build project
  • CodeBuild / CloudWatch integrations:
    • Sends per build logs to CloudWatch Logs and/or S3
    • CodeBuild automatically creates a dashboard in CW Metrics
      • Sum of succeeded/failed builds
      • Avg duration of builds
    • Use CloudWatch Events to:
      • detect failed builds (& trigger notifications)
      • schedule regularly timed builds (target would be CodeBuild project)
      • react to CodeBuild event patterns (state change, success, failure, phase change, etc…)
    • Use CloudWatch Alarms for failures based on threshold metrics
    • Use Events/Lambda/SNS for automation & notifications
    • Can run tests 5 minutes –> 8 hours (Lambda can only do max 15 minutes)
  • Validate CodeCommit Pull Requests (PRs)

One thought on “AWS DevOps Pro Domain 1: SDLC Automation (part 1)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.