SnapCI: everything I ever wanted
• Julian Simpson
Some time ago, I worked at ThoughtWorks. It was my job to ensure that the CI server was accurately giving feedback to the team,and that we had a remote hope of deploying applications into production. ThoughtWorks had (and has) some incredible people: I probably should have stuck around longer.
At the time, I was frustrated with the CI tools that we had. The three different ports of CruiseControl that we tended to use (probably why Jenkins ate CruiseControl's lunch) all suffered from similar issues:
- Configuration wasn't often easy, especially when dealing with configuration that spanned multiple projects/jobs. You could write a build-breaking configuration which would break the next commit, through no fault of the developer who committed it.
- From about 2005 it was clear that this Build Pipeline thing had legs. But it took a long time until the tools caught up with the Build Pipeline concept.
The industry still has a long way to go to help us fulfil the promises of Agile and Continuous Delivery; but I'm happy to report that my problems are solved, and the tool I'm using to solve it is Snap CI, from my old colleagues at ThoughtWorks.
We're using it on a few Git based projects at work, and it's very reliable and simple. The biggest project has 4 stages:
- Fast Feedback
- AMI
- Staging
- Production
It shows one real build pipeline for all of those stages. Any time I make a configuration change to a pipeline or any of it's stages, the entire pipeline triggers.
Git helps a lot; if I need to know what the current HEAD is, the build scripts can just ask; each stage has the same access to git. GitHub integration means that we can control access to Snap via Teams in Github.
We can store passwords and credentials securely in the pipeline.
They're also rolling out Docker support.
The best part of it? I'm not slaving over a hot CI server; I'm working on projects that are useful to my employers instead. There's never been a better time to be a developer.