A couple of weeks ago we started a closed beta for Changehub, so it’s a good time to give an introduction to this tool and talk about its history and origin.
What does it do
Why it was built
The first mention of Changehub was on our team retreat in Lisbon in the fall of 2014. We discussed how project managers could give better updates to clients about the state of their projects. We began to think about a tool to better communicate about which bugs were fixed, which features were added, and the possibility to automate this entire process.
Given we’re developers and we wanted to have started yesterday, we quickly set up a hackathon and dove into the topic.
The idea that sprouted from the hackathon was to use specially formatted commit messages. e.g. [ADDED] Feature X or [FIXED] Annoying bug #201.
These messages would then be parsed and put into the correct sections of the changelog. It took us not more than an hour to get a working proof of concept.
What happened next
A few weeks after that, some of us decided to continue working on the tool during our innovation Fridays. We like to include the whole team to get as much varied input as possible. One of the biggest changes we made to the initial proof of concept, was switching to a pull request message instead of commit messages. The argument being that git commits aren’t very useful to keep track of changes that need to be understood by humans (which is a critical point for a good changelog).
Once we had a real solid MVP we decided to give it a test run on one of our projects. A project manager provided the client with a URL where they could see the latest releases and the changes scheduled for the next release. This changelog was updated whenever a developer’s pull request got merged. Awesome. The client was amazed that he could see what was actually done and ready to be shipped, instead of the usual estimates he normally received. This also lowers the email traffic, which makes everyone super happy.
See what was actually done and ready to be shipped, instead of the usual estimates
We quickly found that writing these changelogs in pull requests was also very useful for other developers. They could easily see what the goal of the pull request was, which ultimately also improved our development quality. It resulted in better (and faster) code reviews since the developers knew the context of the changes being made.
Currently, Changehub is still in active development, but we released a Beta version! So if you’re interested in giving it a test-drive and provide us with the feedback you can signup for the beta here. We love feedback both positive and negative, functionality requests as well. Shoot!
Our goal is to make this tool useful for a lot of people and not only developers. We also want to have the content adapted automatically for copywriters (think changelogs on iOS app releases) and project managers too.