From time to time when reading around different areas of tech (mostly to keep up with the current trends), I write down a few ideas that I think will make for good blog posts. I recently had an idea of doing a series of posts that compared popular CI/CD tools. This will provide me with the benefit of some exposure and familiarity with the tool and to also use it with my Terraform AWS OpenVPN Ephemeral repo to see how the tool stacks up!
So similar to how I set up CircleCI and GitLab with this Terraform AWS OpenVPN Ephemeral repo, I figure, let’s try and use some more popular CI/CD tools and see if they work and how hard they are to setup.
First up - Travis CI!
Travis CI Setup
Travis CI has a pretty decent free tier, however, the signup process is not as straightforward as compared to CircleCI and GitLab. You can sign up with your email and add your credit card, but to me, the UI and layout are a bit disorganized.
This tutorial webpage is quite great, however, I am very confused as to why you would use GitLab as your SCM and Travis CI as your CI/CD tool. GitLab has CI/CD capabilities and runners which integrate very easily and run very quickly with GitLab SCM repos, so this feels outdated to me.
Side Note: there was a pretty interesting security incident right after I signed up which was a bit unnerving, but honestly these things happen in our industry. At least Travis CI was honest about it and disclosed the breach. I’m not going to stop using the project solely because of a breach.
After exploring the capabilities of Travis CI, I had to alter the workflow of how I intended to use my Terraform AWS OpenVPN Ephemeral repo differently from how I set up CircleCI and GitLab, so it would have to work as follows:
- Create a private
artifactsS3 bucket - Run the terraform commands to create the resources and then upload the Terraform state and OpenVPN profile to the
artifactsS3 bucket on anapplybranch - Download the Terraform state from the
artifactsS3 bucket and then perform a Terraform destroy on adestroybranch.
This was all set up in this openvpn-ephemeral-travisci-template and the .travis.yml file is where the bulk of the logic is.
Sadly, the testing for this template did not work as expected. The terraform-apply stage got stuck in a loop waiting to connect and download the openvpn.ovpn file from the EC2 server created. Rather than continue to investigate what exactly was causing the issue with either the Travis CI runner or the Terraform module itself, I had decided that I had seen enough to evaluate that Travis CI is not a fit for this particular use case. This is not a bad thing; why spend more time trying to fit a square peg into a round hole? Further, I had also gained a little bit of understanding about Travis CI to form an opinion on its ease of setup and use, so the exercise completed my goals even if the workflow ultimately failed.
What I liked
I liked the ease of integration with GitHub to Travis CI as GitHub is where I host my code repos. It took very little time and effort to set up Travis CI and have it respond to Pull Requests being made of my GitHub repo. I also liked how quickly it fired whenever there were Pull Request events. I have seen slowness with GitHub to GitLab Pull Request events, but Travis CI is fast to start jobs and runners, as is CircleCI.
I also liked how there are specific instance types and programming languages and the tooling definitely feels more focused on building the application based on your programming language of choice. The Terraform AWS OpenVPN Ephemeral repo is all written in Terraform HCL so it’s not really the best use case for Travis CI.
What I didn’t like
Not a huge fan that Travis CI automatically associated me with my GitHub organizations as well—I kinda wanted to just test out my own personal projects and not freak out I would break an organization’s existing project and Travis CI pipeline, but c’est la vie. I also found that finding the Pull Request events was not that straightforward; I could not see any info until I hit the Requests section of my repo:
A big issue I had was that my .travis.yml file was completely malformed and unfortunately, finding a linter is not as straightforward as it is with GitLab and CircleCI. I did eventually find this Travis CI Build Config Explorer which is currently in Beta, although I found this from a Travis CI forum, not through the documentation.
I also found it difficult to work with not being able to pass artifacts between CI jobs, when that functionality is quite simple to set up with GitLab and CircleCI.
Finally, I believe you can only use custom Docker images with Travis CI Enterprise which is a drawback for freebie users like myself. If I have a Docker container/environment that I know compiles my application, I am happy to use it with any CI/CD provider. However, this does not appear to be the case with Travis CI as it is with GitLab and CircleCI.
Recap
- Travis CI has a good free plan and is fairly straightforward to setup
- For infrastructure focussed projects, I would not recommend it over GitLab and CircleCI
- For projects that require application builds in certain programming languages, I’m sure it works great 🙂