Github Actions & Workflows for CI/CD

Hara Kang — Mon, 25 May 2020 16:05:42 +0000

It's been already three months since I have joined DataHunt, but to be honest, I haven't been able to work on automating our development workflows due to lack of time. Endless march of demos and actual product delivery in a very short time span left us with untested code and no reliable CI/CD pipeline during code push and deploy.

Therefore, I decided to spend some time this week rebuilding our test suites and structuring CI/CD so that we could deliver our software in a more stable way from now on. My goal was to integrate integrations tests to Github CI and deploy to Heroku only when the test suite succeeds.

There were several options that came to my mind:

Jenkins CI
Travis CI
Heroku CI
Github Actions

Of all these solutions, I am leaning toward Github Actions.

Jenkins & Travis CI

I had some experiences with Jenkins CI at my previous company since our team used it for most of our CI/CD flow. Jenkins is easy to install, use, and quite flexible due to its configurable nature. If your team uses a lot of tech stacks, including mobile, web, backend with various languages, then I think probably this is the best option. However, its ease of use just stretches as far as to a very basic task. If you don't mind using locally installed databases or softwares, then Jenkins will probably provide you with the fasted setup and build speed, since what you have to do is just installing softwares on a machine and running scripts (probably little bit of permission settings). But if you want to use containers for your build environment for providing a consistent and isolated build environments, then things become a little more complicated in Jenkins (at least this is true for my personal experience). You have to manually install docker plugins and set up a containerized build system, which felt like pain in the ass when I tried to set up one for Kakao Android SDK project.

On the other hand, Travis CI, Heroku CI, and Github CI all offer solutions based on containers that provide isolated build environments. It is true that build speed might slow down because containers must provision necessary services in pre-test stage, but there is a larger benefit in switching because you don't have to upgrade local databases or other environments yourself.

Travis CI

Travis CI is quite good when you host an open source project on Github, since you get the service for free. However, our project was private and the pricing seemed a little expensive at our stage. I am currently using it for kakao_flutter_sdk open source project that I am maintaining for Kakao organization.

Heroku CI

Heroku CI also seemed a good option since we were on the PaaS and clicked well with the Heroku pipeline feature (dev, staging, and production env setup, deploy, etc...) we were using.

Below screenshot shows automated tests running on pushing to specific branches.

However, there were several downsides.

Builds seemed slower than other alternatives.
Databases could be provisioned in-dyno but there is no guarantee that every add-on that we use will be available. It would be impossible to run whole integration tests if just one add-on isn't available in Heroku CI env.
CI/CD will be stuck with infra. If we migrate to AWS in the future, redundant work must be done to setup CI/CD again with other alternative.

Therefore, I decided to try the last option, GitHub Actions.