By Peter Richards, CTO
This is a bit of a change from our normal topics and was inspired by a conversation I had with Graham Parkins, Technical Director at Show Data, about the tools our tech teams use.
As CTO at Gleanin I am responsible for our product and the software we produce. A part of my role also means ensuring the team has the correct tools and processes in place. Our development process is one step away from Continuous Delivery – we often trigger deploys several times per day. Here’s a little run down of the tools we use and how they work for us.
For source control (or version control) we use GitHub, which is based on Git. I have used this for every project since I left IBM 10 years ago and I think it’s awesome. Git can be a bit of a shift in mindset from other source control products but GitHub have built an amazing product on top of it, including allowing integrations from other 3rd party services (more on this shortly).
We have a master branch which is what gets deployed, and changes are made in branches. Once work in a branch is complete, changes are merged back into master via Pull Requests. Pull requests let us review the code changes, make comments, and keep related changes nicely organised.
To support deploying so often, we need to have confidence our product is working correctly. In order to do this, we have a test suite that must be green in order to either merge changes into the master branch, or deploy master (with our process, master should never not be green).
We can run these tests locally on our development environment but they are also run automatically by a third party service (CodeShip) each time someone pushes code to a branch. CodeShip is another great product and integrates with Github really nicely – if there is a test failure, a notification is added to the pull request that introduced it and we will not merge the changes into master.
While there is no replacement for human code review, more recently we started using CodeClimate which performs static code analysis. It gamifies code quality by giving you a score and has helped & encouraged us to improve the quality of our code. This also integrates with pull requests and GitHub to add a pre-merge check that no transgressions have been introduced. Code is a funny thing though, sometimes you need to know when the automated recommendations should be ignored.
CodeClimate have a good series of onboarding emails too that help with how you should use it – i.e. don’t go and spend a month getting the score up, but don’t introduce issues and when you’re changing an area leave things better than you found them.
Here’s a screenshot to give a feel for what a pull request looks like with the CodeShip and CodeClimate integrations
This can be quite a personal choice for developers but recently we’ve all switched to Atom – the main reason being that it supports CodeClimate’s code analysis during development and highlights issues as soon as you save a file.
As a team we have been using group chat for years – first with Hipchat and more recently with Slack. These are great for team and 1:1 chats but the integration of our other tools with them make it really easy to have an overview of what is happening. If a build passes or fails, we get notified, if someone deploys, we get notified, if our code score goes down we get notified. At first I thought these might be a distraction, but it is not at all and is very helpful and reassuring to have oversight of what’s going on.
We’ve been playing a little bit with containers and Docker which is interesting and getting main stream. I think our first use case will be to create images for our dev environments, so anyone in the team (or joining it) can run any of our projects in identical environments by running a single command. We develop on Macs and updates to OS X (now macOS) often change compiler settings causing disruption, containers is one way to solve that.