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:
Create a release, e.g. v1.0.0:
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:
The release automatically creates the corresponding tag:
This triggers finally the whole CI/ CD pipeline:
And finally everything is in production as planned:
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: