CI/CD

Continuous Integration

• Developers push the code to a code repository often
  • GitHub, BitBucket, CodeCommit (in AWS) etc…
• A testing / build server checks the code as soon as it’s pushed
  • Jenkins CI, TeamCity, CodeBuild (in AWS), etc…
  • The developer gets feedback about the tests and checks that have passed / failed
• Helps
  • Find bugs early, fix bugs
  • Deliver faster as the code is tested
  • Deploy often
  • Happier developers, as they’re unblocked

Continuous Delivery

• Ensure that the software can be released reliably whenever needed.
• Ensures deployments happen often and are quick
• Automated deployment -> Shift away from e.g. “one release every 3 months” to 5 releases a day.
• CodeDeploy in AWS, Jenkins CD, Spinnaker, etc…

Technology Stack

• AWS CodePipeline allows you to automate all steps of the deployment:

  Step	Name	AWS	Others
  1	Code	CodeCommit	GitHub, GitLab etc..
  2	Build & test	CodeBuild	Jenkins CI, TeamCity etc..
  3	Deploy	ElasticBeanstalk, CodeDeploy	Octopus
  4	Provision	ElasticBeanstalk, CloudFormation	Terraform

• CodeDeploy

  • Two deployment options:
    1. In-place deployment: EC2/On-Premises apps are stopped & updated & validated.
    2. Blue/green deployment: Using slots (deploy A -> switch to A -> stop B) with minimal downtime and rollback capabilities.
       • EC2/On-Premises: Must have one ore more EC2 with tags or ASG
       • Lambda
         • Canary: Traffic is sifted in two increments, 90% to first version, 10% to second before 100% to second.
         • Linear: Traffic is shifted in equal increments with number of minutes e.g. 10% per minute.
         • All-at-once: All traffic is shifted at once.
       • Amazon ECS: Task set switches

CloudFormation

• Code will be deployed and create / update / delete infrastructure
  • Can be JSON or YAML.
• Can be part of disaster recovery strategy.
• Declarative way of outlining AWS infrastructure for any resources (most of them are supported)
  • CloudFormation provisions in the right order with the exact configuration that you specify.
• 💡 Allows re-use the best practices around your company for configuration parameters.
• Templates
  • You can upload in S3 and then reference in CloudFormation
  • Update a template
    • Can’t edit previous ones.
    • Have to re-upload a new version of the template to AWS.
  • Building Blocks
    • Cloud formation template consists of components and helpers:
      • Template components
        1. Resources: your AWS resources declared in the template (❗ mandatory)
        2. Parameters: the dynamic inputs for your template
           • Allows you to parameterize & prompt inputs while deploying.
        3. Mappings: the static variables for your template
        4. Outputs: References to what has been created
        5. Conditionals: List of conditions to perform resource creation
        6. Metadata
      • Template helpers
        1. References (Logical IDs are used to reference resources within the template)
        2. Functions
• Templates
  • JSON or YAML text file that contains instructions for building out AWS environment
• Change sets
  • Before making changes to your resources, you can generate a change set, which is a summary of your proposed changes, e.g. resource A will be deleted.
• Stacks
  • The entire environment described by the template and created, updated, and deleted as a single unit
  • Related resources in a template.
    • When you update stack, it updates the resources
  • Can rollback on failure after timeout in minutes.
  • Termination protected with stack from being accidentally deleted.
  • Monitoring
    • Fires events such as on resource creation
    • Can have monitoring time (CloudFormation monitors resources during X minutes after creation)
    • Can set up CloudWatch alarms if something fails.
  • Can have IAM role or policy to deny/allow access.
  • Can use sample template or create one in Designer.
  • Identified by name
  • Can have input parameters that’ll be filled from portal.
  • Reusable output information
    • It’s output information (key, value, description) can be imported by other stacks by using an unique export/import name.
  • Stack Sets lets you create stacks in AWS accounts across regions by using a single AWS CloudFormation template
  • Operations
    • Deleting a stack -> deletes every artifact created by CloudFormation
    • Deploying templates/stacks
      1. by uploading YAML files directly or referencing to Amazon S3 URL
      2. Use a sample template
      3. Create template in Designer
         • Helps you to see resources & relations
         • Might be good for PowerPoints - ❗ Redeploying a stack deletes old instances.
    • Changing a stack
      • Done using Stack change sets
      • Warns you about resources that’ll be deleted, modified and added.
      • Drift: difference between the expected configuration values and actual deployed.
        • Allows you to better manage your CloudFormation stacks and ensure consistency in your resource configurations
• Can deploy Elastic Beanstalk that’ll then deploy:
  • E.g. EC2, ALB, ASG, RDS
• IAM Conditions for CloudFormation
  • cloudformation:TemplateURL: Ensure template in TemplateURL is used for e.g. update/delete.
  • cloudformation:ResourceTypes: Specify which types of resources can be created or updated.
  • cloudformation:StackPolicyURL
    • Stack policies prevents stack resources from unintentionally being updated or deleted during stack updates
    • You define which actions (t.ex. update) are allowed on which resources in a JSON file.

Benefits

• Control
  • No resources are manually created / configured.
  • Code can be version controlled e.g. using git.
  • Changes are reviewed through code
  • Cost control:
    • Each stack has ID: follow-up costs.
    • Estimate costs of a stack.
    • You can automate deletion of templates at 5 PM and recreation at 8 AM safely.
• More productivity:
  • Destroy and re-create an infrastructure on the cloud on the fly.
  • Automated generation of diagram for your templates!
  • Declarative programming (no need to figure out ordering and orchestration)
• Better separation of concerns:
  • Many stacks for many apps, and many layers.
  • E.g. VPC stacks, network stacks, app stacks

OpsWorks

• AWS managed service for Chef & Puppet
• They work great with EC2 & On Premise VM
• Alternative to AWS SSM (Systems Manager)
• OpsWorks stacks
  • Groups applications into layers depending on Chef recipes
  • No need to provision chef server
  • Uses the embedded Chef solo client that is installed on EC2 instances on your behalf

Systems Manager

• Serverless & free & open-source
• Is built-in in AWS AMIs
• Does not require any jump-boxes (bastion hosts)
• Can run Ansible, PowerShell DSC or any script from S3 through Run command.
• Can use AWS Systems Manager Automation
  • Leverages documents for tasks that can be automated.

Chef & Puppet

• Help with managing server configuration as code
• Helps in having consistent deployments
  • Can automate: user accounts, cron, NTP, packages, services
• They leverage “Recipes” or “Manifests”
• Similar to SSM / Beanstalk / CloudFormation but they’re open-source tools that work cross-cloud.

Serverless applications

• Serverless applications are e.g. Lambda, DynamoDB, API Gateway…
• To be order to locally run, debug and easily deploy serverless applications you can use:
  • AWS Serverless Application Model (AWS SAM)
    • Open source tool used to package, test, and deploy serverless applications
    • YAML based infrastructure as code.
  • serverless.com
    • Vendor-neutral (Azure, Google, AWS) serverless framework.
    • YAML-based infrastructure as code.

---

---