Deployment Automation

# CHAPTER 7

Deployment Automation #

1. Introduction #

2. Learning Objectives #

• Define the operational goals of the deploy stage.

• Configure a GitLab CI job to execute an SSH deployment.

• Utilize the environment keyword to track deployments.

• Implement rules to restrict deployments to the main branch.

• Implement manual approval triggers (when: manual).

3. Beginner Explanation #

• The Build Stage: The journalists finish typing the articles. The layout team finalizes the digital PDF of the newspaper page.

• The Test Stage: The Editor-in-Chief proofreads the PDF to ensure there are no typos.

• The Deploy Stage: The Editor hits a large red button. The digital PDF is instantly sent over a secure wire to the massive physical printing presses in the basement. The machines turn on, ink hits paper, and the newspaper is printed and thrown onto delivery trucks.

Deployment Automation is the wire connecting the Editor's desk to the printing press. Nobody has to walk downstairs with a USB drive.

4. Anatomy of a Deployment Job #

deploy_to_production:
  stage: deploy
  image: alpine:latest
  
  # 1. Ensure the Runner has an SSH key to log into the server securely
  before_script:
    - apk add --no-cache openssh-client
    - mkdir -p ~/.ssh
    - echo "$PRIVATE_SSH_KEY" > ~/.ssh/id_rsa
    - chmod 600 ~/.ssh/id_rsa
    - ssh-keyscan $SERVER_IP >> ~/.ssh/known_hosts
  
  # 2. Log into the remote server and deploy the code
  script:
    - ssh user@$SERVER_IP "cd /var/www/html && git pull origin main && restart-server"
    
  # 3. Tell GitLab this is a deployment job
  environment:
    name: production
    url: https://my-website.com
    
  # 4. CRITICAL: Only run this job if code is pushed to the main branch
  only:
    - main

5. Multi-Environment Workflows #

• Staging: An exact clone of the live website, but hosted on a secret URL (e.g., staging.my-website.com).

• Production: The live website.

You can configure GitLab to deploy to Staging automatically on every commit, but deploy to Production *only* when code is merged into main.

6. Mini Project: Manual Approval Gates #

We can add a simple rule to our deployment job:

deploy_to_production:
  stage: deploy
  script:
    - echo "Deploying to production..."
  environment: production
  only:
    - main
  # This pauses the pipeline until a human clicks the "Play" button in the UI!
  when: manual 

Step-by-Step Walkthrough:

1. 1. Add the code above to your .gitlab-ci.yml.

1. 2. Commit and push.

1. 3. Go to the GitLab Pipelines dashboard.

1. 4. You will see the pipeline run, but the deploy stage will have a "Paused" symbol ||.

1. 5. The deployment will not execute. It waits indefinitely until you click the literal Play ▶ button next to it. You have instituted a manual Continuous Delivery gate!

7. Tracking Environments in GitLab #

8. Best Practices #

• Immutable Artifacts: The golden rule of CI/CD is "Build Once, Deploy Many." Never recompile your code or rebuild your Docker image in the deployment stage. The exact artifact that was built in Stage 1 and tested in Stage 2 is the exact artifact that must be deployed in Stage 3. This guarantees that what you tested is exactly what is running in production.

9. Common Mistakes #

• Deploying Feature Branches: Forgetting to add the only: - main rule to your deployment job is a massive security risk. If a junior developer pushes an experimental feature branch named feature/broken-ui, the pipeline will trigger and instantly deploy their broken, unreviewed code over the live production website.

10. Exercises #

1. 1. Why is it a critical security requirement to restrict production deployment jobs to the main branch?

1. 2. What is the operational difference between configuring a job with when: always versus when: manual?

11. FAQs #

12. Summary #

13. Next Chapter Recommendation #