But It Worked on My Machine
But It Worked on My Machine
There are many reasons code could pass on one machine but fail elsewhere. See how using a personal CI server with Docker can help solve this problem.
Join the DZone community and get the full member experience.Join For Free
The need for DevOps innovation has never been greater. Get the results from over 100 business value assessments in this whitepaper, Digital Darwinism: Driving Digital Transformation, to see the positive impact of DevOps first hand.
Anyone familiar with software development can attest to hearing "But it worked on my machine," or a variation of it. There could be a multitude of reasons for code to pass on a developer's machine but fail everywhere else. Some of the common reasons for a particular changeset or commit to fail on the development team's official continuous integration system are:
Differences in system environments.
The commands used to run and test the build ("-Dmaven.test.skip=true" anyone?).
Files and/or dependencies that only exist on the developer's machine.
Bugs in the code.
One of the primary objectives of a CI system is to catch build issues as soon as the code is checked into the version control system. While compile issues are identified almost instantaneously, it takes a bit longer for a CI system to catch regressions or new bugs. But then again, code bugs seldom happen - we software engineers never make coding errors, do we?
The amount of time it takes for a CI system to report the outcome of a run––often called the feedback time––depends on the size of the codebase and the number of automated smoke and integration tests. Additionally, if a failed run is an aggregation of changesets from multiple developers, identifying the root cause takes even longer. Such delays in the feedback time are clearly a source of frustration for all stakeholders involved. For what it's worth, modern CI systems do their best to identify offending changelists, albeit prone to false positives and other errors.
To address this issue and cut the feedback time, developers should be encouraged to setup and use a personal CI server before posting code reviews or checking in code. The advent of Docker makes such a setup a breeze. Here's a sample development flow:
Based on requirements, a developer makes changes to the codebase on his or her local machine.
After a satisfactory outcome, the developer creates a changelist and kicks off a build on their personal CI system.
While the entire suite of automation tests run on the personal CI server––ideally in a Docker container––the developer can attend to other tasks.
After a successful test run, the developer can post a code review and check-in the changes.
Running the changelist on a personal CI server beforehand gives the developer and the reviewers greater confidence in the changes. Ideally, it would also mean that there won't be any issues after the code is checked-in. Which means green builds, a stable codebase, and a happy team.
Now let's switch gears to setup and run one. While there are a number of open source automation servers––like Jenkins and others––to choose from, I will use buildpal.
First, make sure you have Docker up and running on your local machine. Now open up a terminal and run the following command:
docker volume create buildpal-data && \ docker run -d --name buildpal -v /var/run/docker.sock:/var/run/docker.sock \ -v buildpal-data:/buildpal/data -p 8080:8080 buildpal/buildpal
That's it. You should have buildpal up and running. Go to http://localhost:8080. Log in using the default credentials admin/admin123.
Create a Pipeline
Let's use buildpal's code repository to define a pipeline. The first step is to create a repository in buildpal.
All we have to do at this point is to run the pipeline and monitor the build.
Developers working on codebases of any size will greatly benefit by running a local CI server. Code changes can be checked-in with greater confidence. It leads to a higher number of green builds on a team's official CI/CD system, which means a stable codebase and a happy team.
Opinions expressed by DZone contributors are their own.