Continuous Integration is a pretty common concept these days. The idea of a “robot buddy” which builds and runs a bunch of tests across a whole codebase every time a change is checked in to the source code repository seems a generally good idea. There are a range of possibilities how to achieve this, and …
Continue reading ‘Tracking configuration changes in Jenkins’ »
Continuous Integration is a great idea, and usually pretty simple to implement for simple projects. However, these simple projects don’t really exercise the “integration” aspect of the idea. As he build and test process for a project grows in complexity, it almost always grows in duration, too. Typical enterprise Java projects, for example, might fetch …
It’s happened on most reasonable sized projects I have worked on. The benefits of test coverage an continuous integration are obvious and pay back immediately. But, somehow, as the project grows and diversifies, a point is reached where the complexity and run time of the CI process begins to slow down development rather than assist …
Like many teams, I’m sure, we are trying to squeeze every drop of effectiveness out of our time. Manual build and deployment not only takes up valuable time, but also acts as a drag on the development process. Anything which pulls developers out of “the zone” is a bad thing for productivity. We usually use …
Continue reading ‘Build and deployment scripts using “real” programming languages’ »
I’m a strong believer that manual steps should be automated wherever possible. One of the areas of our current product which seems to require an inordinate amount of manual “faffing” is provisioning and deployment. Chef, a ruby system for distributing and automating just these kinds of tasks seems an interesting solution. Home – Chef – …
Continue reading ‘Chef – scriptable multi-machine deployment’ »
Setting up everything needed to get a new developer up to speed, or an old one going on a new workstation can be one of the most irritating aspects of working in software development. I currently use three separate PCs, two of which are now relatively old but largely stable, and one which is newer, …
Continue reading ‘Setting up for a new developer or new workstation’ »
We use ant, a lot, but I’m getting progressively fed up with it so I’m looking for alternatives. Ant has several well-known problems, including: The use of XML makes the syntax very wordy and hard to read Things which should be simple such as refactoring common “code” or transforming filenames are more difficult than they …
Continue reading ‘alternatives to ant: gant, gradle and pjmake’ »