With the upcoming end-of-life for Bamboo Cloud, I’m in the market for a new build server setup. For this1 experiment, I’m returning to an old favourite – Jenkins – paired with a potential new favourite – Docker. In this post, I describe how I’ve set up a Jenkins server in a Docker container, using the Multibranch Pipeline plugin to automatically configure a simple build2.
Came across this article by Steve Blank – “Startup Suicide – Rewriting the Code“. This can be summed up as:
- Under the pressures of growth, some startups allow their code base to get messy.
- This mess – and the pressure to keep it working – results, over time, in a slower delivery of features.
- This leads to a failure to adapt, which is seen as an existential threat to the future of the business,
- The business decides that a rewrite of the product is the way to go.
- This leads to death.
I don’t dispute the main premise of the article, but I do dispute the title. The answer is to rewrite the product. The question is: how do you do that?
I’ve been recommending a similar approach – though not as completely fleshed out – for the last few years. (I organise the spine of my map as a mind map, though – I like spreading it out in 2d instead of just a line)
One of the odder practices of “conventional” software development that I’ve ever come across is the post-release test cycle. It’s something that has baffled me ever since I first saw it; you go through the normal development cycle, including testing, and then you deploy to production – and then you test it again. Sometimes with test cases that weren’t done during development. Why?
“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.
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.
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.