Bring on the Continuous Everything!
I am definitely a junior when it comes to being a software developer as pretty basic stuff can still amaze me. Just like getting a simple Continuous Integration and Deployment setup up and running…
We have been working through a complete rewrite of the site’s core functionality and for a while our smallest concerns were bigger than getting any kind of CI-CD solution working.
The good news is that we have been able to make significant enough of a progress recently, that seeing our code running up on the server more often is not only helpful, but also motivating.

It makes a huge difference, when weeks of writing backend code, working through models, writing countless unit tests, that other than a green/red color in the command line, does not really offer much of a visual feedback that we are on the right track.
Then comes the first deployment to the server, this time manually. Everyone is excited, super fun to get closer and closer to see our work running up on the server. Then when it does: awesomeness!!!
Two main steps that we needed to set up:
First: of course we wanted to make sure that our very detailed test suite is going to run whenever we think a piece of code is ready to get merged. Not that our fingers grew tired of launching the test suite from the command line every time, but having it run automatically will definitely help to avoid any mishaps and stand as a line of defense to avoid merging anything with failing tests.
Second: once all our excitement of the initial manual deployment wore off, soon enough we realized how much easier our life was going to be if the deployment process would be automated. Making sure that only specific branches would get deployed to specific environments after all the corresponding tests successfully passed.
But what CI to use? We were going to go with Travis CI as we have used it before, but our repo being private and not wanted to pay at least $69/month just yet (https://travis-ci.com/plans), tried to find other solutions that are similarly straight forward.
Jenkins is well known everywhere and it made good sense to dive into it. Talking to other peers at junior level and hearing about the steeper learning curve, despite confirming that it is an awesome tool to use afterwards, we were at a point where, we wanted to take a seemingly easier path. Though this decision was not too scientific at that moment, but still a long list of tickets to resolve, we opted to learn more about Jenkins at another time.
Then we came across of Circle CI, which seemed to cover our needs at least for the near future.
Free to use even on private repos and working even without any configuration files being set up, but simply linking up our repo through the Circle CI Dashboard was definitely a great start, so we opted to get familiar with something new and so we went with Circle CI…
Running our tests:
Though without any special configuration file(s) we were able to run our tests automatically, we saw some of our tests failing through Circle CI while passing successfully locally.

Apparently we were not too special and not the first one ever running into this issue: where DateTime object comparison failed. Found the RSpec comparison of datetime objects failing entry on the Circle CI discussion board.
We ended up comparing our DateTime objects after both the expected and the returned values were converted through the .strftime method for all the DateTime object details that we were interested in. For our purpose matching to so many digits deep within any given seconds was not necessary.
Hallelujah! All tests were passing now and we were on a roll…
Deploying a successful build:
Adding the deployment commands was very straight forward. This definitely required us to introduce a Circle CI specific configuration file, but setting up the necessary keys and configure Circle CI to deploy only specific branches went without any hiccups as we followed the step by step instructions and the sample configuration file online.
Don’t mix things up: version 1.0 and 2.0
I hope you will not make this junior/rookie mistake, so I will state the obvious: when checking documentation and trying to troubleshoot, make sure you don’t mix up the Circle CI 1.0 and 2.0 documentation.

I spent some time not understanding why my configuration file was not working only to reach the conclusion that I tried to set up a version 2.0 file as version 1.0 (filename and file locations are different, just to start off with one delta between the two versions) and to top it off, I successfully mixed up the documentations when I started troubleshooting. All is good now, but I could have saved a few rounds of head scratching. Note to myself: assumptions are still very dangerous things…

For now there is a happy ending and we are now enjoying the convenience of running our test suite automatically and for selected branches when all tests passed, we deploy the build to various environments.
When and what adjustments we will have to make in this process is still to be seen, but for now we will keep on building and deploying…
