As a developer, I rely on a CI server to take care of the day-to-day routine of building, testing and deploying software...so much so that I often find myself committing code after every new class or group of methods as a “fire and forget” signal to the CI server to go ahead and run my tests, check my code for style violations, and push a new version to the dev server. When I have finished my train of thought, I can jump into the CI server and either be greeted with a green tick or have a handy (and more importantly authoritative) list of issues to be addressed.
However, for all the convenience that a central CI server brings, there are times when this environment lets me down. Maybe my jobs are at the end of the queue, I can’t deploy to the dev servers during a certain time frame, or the configuration of the build just doesn’t quite do what I want it to do but I don’t have the authority to change it.
This got me thinking: why don’t I have my own personal CI server?
At first, the idea seemed a little counter intuitive. With a bit of effort, I can configure my IDE to do almost everything a CI server does, even if the process in an IDE is tailored for a single user experience. However, there are processes that just make sense to defer to a CI server, like long running tests, production compilation routines with minification and obfuscation, and linting. I don’t want these things taking up my immediate concentration, but I do want them running frequently enough so that when I do need to check the results, I have something meaningful to review.
Perhaps the biggest reason for having a personal CI server is the ability to have a local development environment that effortlessly updates with changes made by other developers. With the rise of microservices and API-driven applications, it is rare that an application stands alone; but I don’t want to be checking out those repos, compiling and deploying manually just to make sure my branch of one component of this ecosystem is still working as expected during development.
Really, all it comes down to is maintaining the development flow and offloading menial manual tasks to a system designed to maintain a suite of custom code. A central CI system does a lot of that, but there are times when a shared system just can’t quite keep up. There is nothing worse that seeing your job at the bottom of the queue or not having the authority to tweak a build process to reflect some new requirements. A personal CI server is just a natural evolution granting the same benefits of a shared CI server but tailored to an individual developer's priorities.
In my next article, I’ll run through the process of getting a basic local Jenkins instance configured as a personal CI server.