Review of CircleCI newly launched 2.0
I have been using CircleCI for more than 2 years and I chose them because of their Docker support at first but also because of their feature where you can SSH into a build if you want to investigate a bad build or try out something. They recently launched their new version 2.0 and I was eager to look at it because of their promised native docker support.
Config
The new 2.0 version uses the same layout so you will be familiar with setting it up, however, there is a new tab called workflows on the left which you will notice. The config file for version 2 has also changed place so now you need to put it at “.circleci/config.yml”. Probably to allow for more config in the future and to combat the endless config files in a root git project, but it is one of those things that adds to the complexity compared to version 1.
The new looks like this:
version: 2
jobs:
build:
docker:
- image: circleci/<language>:<version TAG>
steps:
- checkout
- run: echo "hello world"
which still looks very simple, and you now have to manually specify that you want to checkout the code. That is likely to allow more customization that you can specify whether you want to checkout or not, but it is something you did not have to do in version 1.
Native docker support
You can also see the docker:
tag which is how you specify which environment you want to run your commands in. This is pretty cool and allows for total customization for a build environment. You can have a docker image with all the tools you need and only those and CircleCI will spin that up for you and also incredibly fast if it already exists on that machine the build is placed on! This is really cool!
But as for how easy it was to use CircleCI 1 for beginners to Continuous Integration this feels like a step that makes it a bit more complicated. And this is their demo Node.js for version 2 https://circleci.com/docs/2.0/language-javascript/:
version: 2
jobs:
build:
working_directory: ~/mern-starter
docker:
- image: circleci/node:4.8.2
- image: mongo:3.4.4
steps:
- checkout
- run:
name: update-npm
command: 'sudo npm install -g npm@latest'
- restore_cache:
key: dependency-cache-{{ checksum "package.json" }}
- run:
name: install-npm-wee
command: npm install
- save_cache:
key: dependency-cache-{{ checksum "package.json" }}
paths:
- ./node_modules
- run:
name: test
command: npm test
- run:
name: code-coverage
command: './node_modules/.bin/nyc report --reporter=text-lcov'
- store_artifacts:
path: test-results.xml
prefix: tests
- store_artifacts:
path: coverage
prefix: coverage
- store_test_results:
path: test-results.xml
That is sadly not simple.
Speed of version 2
I upgraded ConnectedCars.dk to the new version 2, it had slowly climbed from 7 minutes to 16 minutes so it was a perfect timing! We had experienced slowdowns on builds sometimes as if there were too many tests going on a specific server, but it had not been too bad. However, the speed on the new version 2 is phenomenal! Our tests have gone from 16 minutes to a mere 3 minutes because of parallelism and 7 minutes in all test times combined. Their new machines are both faster and because of the new config, the docker images we use are cached which means even less wait time.
You can see the graph showing 17 minutes at worst and now super low. They haven’t updated the graph to show correctly the new “workflows” time spent as our slowest build is 3 minutes out of 5 builds, but the graph shows median build time across all 5 builds.
I really hope the speed continues and that it is not just because they just launched it and therefore their majority of customers are not using it yet.
Give me more resources!
One thing that I deeply wanted in their now old version one was that I could throw more hardware at my builds so that they would finish faster, but that was never possible, you were always using the same hardware. That is now possible in version two and you can specify resource class. https://circleci.com/docs/2.0/configuration-reference/#resource_class
They haven’t specified how they will bill for the different classes so at the moment there is no reason not to choose the biggest machines you can get! However getting more CPU cores will definitely solve a lot of slow tests problems that we have had before.
Github Integration and workflows
With the new CircleCI workflows it is really easy to specify things that you want to be done in parallel, something that was not that easy in version one if you were using Docker as pulling images for each parallel test would be slow. You “simply” define your workflows and then also each workflow is then reported to github’s special buildstatus icons. That means that you can have a specific “workflow” for linting and you can quickly give the pull request author an indicator of if that has passed and if not he will now without doing anything.
Summary and afterthoughts
The new CircleCI 2.0 is definitely awesome and comes as I was just about to look at other alternatives for a lack of any new features coming from CircleCI. The increase in build speed is noticeable and really what I wanted, however, the new config and setup is not a beginner friendly as the old version where you did not have to think about docker and steps if you just had a simple Node.js project. There is really some work on to make that better as version 1 wasn’t the easiest as well.
The SSH into a build feature is just as awesome as in CircleCI and still, makes it easy to iterate on a new build config and for debugging slow stuff.
I had to give up using Docker-Compose which I felt was really awesome before as it was the exact same commands I would use in my own development flow that I would tell CircleCI to run, but that does not fit into the new flow of more optimized docker steps, however, I think that is something that they should look at to simplify it!
I will give the new CircleCI a solid A-
, it is really good and much improved but to get an A+
I think they need to improve how easy you can get started.
I will continue to be a happy customer!