Git, Feature Branches, and Jenkins – or how I learned to stop worrying about broken builds

I mentioned in my last post how we have started using Feature Branches with Git and Jenkins. In that, I rather casually mentioned that

“The build server uses the Git plugin for Jenkins to monitor all the branches on the local repository. Whenever a developer pushes to the repository, Jenkins will see the change and try to merge it into the stable branch. If the build passes, the merge is committed. If it doesn’t pass, the FeatureBranch doesn’t get merged – and it will stay unmerged until another change is made against it.”

This feature means that broken builds have almost no impact on team productivity. In fact – it can even be more productive to allow a broken build than to try to prevent it all the time.

Continue reading “Git, Feature Branches, and Jenkins – or how I learned to stop worrying about broken builds”

Making Parallel Branches meet regularly with Git and Jenkins

If you’ve been following my tweets recently, then you’ll know that we’ve recently converted the majority of our projects at work from Subversion to Git for our source control. We didn’t just do this because we wanted to play with a new shiny toy, but because we hope to achieve a new way of working. That’s what I want to describe here.

Continue reading “Making Parallel Branches meet regularly with Git and Jenkins”

Git Tip – Use different SSH keys per server

A lot of public git repos are configured around the use of SSH keys for authentication. It’s a good idea to use different keys for each server.

Doing this requires two steps:

  • create a unique key for the server (and submit it as normal)
  • configure your SSH client to use the new key just for that server

Creating the key is easy (Linux/Mac – sorry, Windows users) – ssh-keygen -f ~/.ssh/site_key (rename site_key as appropriate)

Then, you need to add a section like this in your ~/.ssh/config file:

Host    site_name
IdentityFile ~/.ssh/site_key

(Again, change site to whatever is appropriate)

Congrats! You’ve now got a unique key just for one site – this means if they happen to get compromised, all you need to do is regenerate the key, and away you go.

(Of course, you may want to use passphrases, and other appropriate measures, on your end – but that’s good advice anyway)

Agile – it’s not about the tools you use

The title says it all, but I thought I’d spend about eight hundred or so words saying more. 😉

I’ve seen a number of people think that “being Agile” is about having a build server, or about using Kanban, or an Agile project management tool. It’s not about unit testing, or pair programming, or continuous delivery, or devops, or any of a hundred other buzzwords. Don’t get me wrong – well performing Agile teams will be using these kind of tools and practices. But that’s not what makes them Agile.

Continue reading “Agile – it’s not about the tools you use”

Selenium Trick: Using a different DNS

I love Selenium. It’s a great tool, that does a damn fine job. But one thing I’ve been wanting to do for a while is to get it to use a different DNS server to the box it’s running on.

Here’s how you do it:

java -Dsun.net.spi.nameservice.provider.1=dns,sun -Dsun.net.spi.nameservice.nameservers= -jar selenium-server.jar

(Caveat: may not work on non-Sun JVMs. Does work on OSX, though…)
Continue reading “Selenium Trick: Using a different DNS”

Maven – still giving me the shits

Some months ago, I wrote about how the Maven Eclipse Plugin 2.7 release didn’t fix a bug introduced in 2.6

Well, neither does the newly released 2.8 version.

Guys, I know you didn’t hear me earlier, but for pity’s sake – DO NOT RELEASE SOFTWARE while you still have critical bugs open. If you don’t want to fix the bugs, edit the issue so it’s no longer bloody marked as critical.

OSGi Diaries – Creating A Bundle

Covers turning the simple web app from the first installment into a simple web app using an OSGi Bundle.

In the first installment, I outlined a simple web application. In this post, I will be turning that application into two parts – an OSGi bundle, with a client web app.
Continue reading “OSGi Diaries – Creating A Bundle”

OSGi Diaries – A short series

I’m going to be spending some time over the next couple of weeks learning about OSGi – there is an application at work that we want to try and make more modular. In particular, we’d like to be able to share the back tier with more front end clients. The more conventional modularisation techniques, such as EJBs, have been tried and didn’t work fairly well. Simply creating more deployments is prohibitive, due to hardward And before someone asks “why not just stick a web service on it and share that way” – some of the front end clients will be those web services. To cut a long story short, one of the options we want to check out is OSGi.

The only problem is that there isn’t much in the way written up on the web about writing OSGi components – at least not without invoking magic tools (e.g. Maven plugins) that don’t work on any version of any tool developed six months later. Which is odd, because OSGi, as a spec, doesn’t look that hard to write too. So, I thought I’d write up a series describing the initial investigative spikes, starting as close to the metal as possible and working up.
Continue reading “OSGi Diaries – A short series”

Why positive thinking works – in my opinion, anyway.

I saw an an article on Seth Godin’s blog about positive thinking. Godin makes the valid point that people who think positively tend to succeed more, in part because their confidence means they don’t second-guess themselves. You can easily waste a lot of energy debating what to do.

A point that Seth didn’t cover is that positive thinking means it’s more likely you will attempt something new: if you feel you can accomplish a task, you’re more likely to try. Sometimes, when you try something new, you will succeed. Other times you will fail. When you fail, there’s a chance you will learn – and learning makes it easier to succeed next time.

One of the key take aways of agile development for me is “experiment, and fail early”. Fail early, fail often, fail cheaply. And learn every time.

Software and Obama’s Victory

from Martin Fowler: Software and Obama’s Victory. I like the last org model shown; it would be very interesting to work in a company structured in such a fashion, with middle management acting as guides & facilitators, instead of intermediates, filters and superiors.