Github Actions - The CD PRD part

Sat, 7 Dec. 2019 by Thomas Bendler, approximately 3 min to read.
#github #actions #ci #cd

Last but not least, I need to deploy the generated website code to my production environment, at least when I’m happy with the results from the QA deploy. Till now, the trigger to start the deployment was the push of a commit. When we talk about the productive deployment it makes sense to introduce another flag that must be set before something is deployed to production. Fortunately here comes git into the game. Git allows us to tag a specific commit. Tagging a specific commit in a defined way is the flag I use for the production deployment. Here you see the release.yml that I use for my production deployments:

name: Release Workflow

on:
  push:
    tags:
      - "v*" # Push events to matching v*, i.e. v1.0

jobs:
  deploy:
    name: CD Pipeline PRD
    needs: test
    runs-on: ubuntu-latest
    steps:
      - name: webfactory/ssh-agent
        uses: webfactory/ssh-agent@v0.1.1
        with:
          ssh-private-key: $
      - name: Checkout master
        uses: actions/checkout@v1
      - name: Set up Ruby 2.6
        uses: actions/setup-ruby@v1
        with:
          ruby-version: 2.6.x
      - name: Set up lftp
        run: sudo apt-get install lftp -y
      - name: Setup bundler and required gems
        run: |
          gem install bundler
          bundle install --jobs 4 --retry 3
      - name: Build and deploy the website to PRD
        run: bundle exec rake deploy:production
        env:
          SSH_DEPLOY_SERVER: $
          SSH_DEPLOY_USER: $

The most import thing is the “on -> push -> tags” part. I still deploy with the push event, but only if the commit is tagged starting with a “v”. So when I tag my commit as “v1.0.2” it will be automatically pushed to production. The even better part of this solution is, I don’t need a special development environment to push a commit to production, it could be completely done from the Github web interface. To do so, you need to go to the releases tab of your code:


Github release tab
Github release tab

Create a release, e.g. v1.0.0:


Create a release
Create a release

As soon as the version tag is pushed to the Github platform, the whole CI/ CD chain starts. This means, the development.yml and release.yml instructions run in parallel and, when everything went well and no errors were detected, the web-site goes straight into production:


Create a release
Create a release

Create a release
Create a release

The release automatically creates the corresponding tag:


Create a release
Create a release

This triggers finally the whole CI/ CD pipeline:


Create a release
Create a release

And finally everything is in production as planned:


Create a release
Create a release

I hope you enjoyed my three posts on how to set up and how to use Github Actions. So far I’m quite surprised how flawless and good the CI/ CD pipeline already works and I didn’t find any major caveats so far that prevents me from using Github Actions. I’m already quite eager to migrate some of my other repositories as well to get more inside into what is possible on Github Actions and whatnot, but for now, that’s all I could tell. I’ll keep you updated when I had migrated more projects.

See also:


Share on: