Release Cycles of the Fast and the Furious
February 28th, 2011 by Benjamin Pollack
One of the things that I've been arguing is a key advantage of Mercurial, and distributed version control systems in general, is that they let you iterate much more quickly than traditional systems. This stems from many areas—Mercurial's operations are generally faster, its superior branching ability means we can easily keep developing new features even while we’re in the release candidate phase, and its vastly better code auditing makes it a lot easier for us to find problems when they arise—but that’s all for naught if you don’t have anything to show for that faster cycle.
We do. Beginning this week, the Kiln team will be aiming to put out a new version of Kiln On Demand every two weeks. Some of these releases will be bigger than others, obviously—on any given release, we may only have bug fixes that are actually ready for deployment—but it means that the time between you reporting a bug and you getting a fix for it, or between a feature being completed and it showing up on your On Demand account, will be drastically reduced.
So how’s the new release cycle working for us so far? Well, if you logged into Kiln on Thursday, you’d find quite a few things that didn’t exist on Monday. Let me point to just five:
Managing lots of repositories just got a lot easier
One thing that we’ve noticed is that distributed version control systems tend to encourage you to create lots of repositories and forks and branches. That’s all well and good, but it can make trying to keep tabs on everything going on extremely complicated. Kiln 2.3 tried to solve this problem with a new “Related” tab for your repositories. While we felt that was a step in the right direction, we thought it wasn’t quite there. So I’m really happy to announce the new and improved “Related” tab:
Our goal with this interface is to make it easy for you to see exactly what the differences are between any two repositories. We’ve taken inspiration from the GitHub network graph and our Incoming and Outgoing tabs and married it with Kiln’s Electric DAG to bring you something that we believe is more powerful than either. Our hope is that this interface will make it very easy to see exactly what's merged in any given set of branches, letting you quickly get tabs on what all of your team’s working on, and what the status of any given release branch is.
You can read more about managing multiple repositories over on the Kiln StackExchange.
Public repositories are a lot more friendly
One of the little-known features that launched with Kiln 2.2 were public repositories. A lot of companies, including Fog Creek, have a few components that they want to release to the public. Kiln 2.3 introduced the concept of making a project public, allowing you to share select code with the world without exposing the rest of your Kiln installation. This worked great, but discovering what was available in a Kiln install was a lot more difficult than it should’ve been, due to the fact that unauthenticated users were simply sent to the Kiln activity feed.
Beginning with Kiln 2.4, when an unauthenticated user hits a Kiln site with public repositories, they’ll be given a list of all the public repositories on that system. We think this is a lot more discoverable, and provides new users with a much better starting point for delving into what public sources you’ve made available. You can try out the new system at http://mirrors.kilnhg.com/, our dedicated repository mirrors site, where you can follow, browse and search the code for Mercurial, Python, Vim, Rails, Redis, and Django, all from the comfort of Kiln’s interface.
Code reviews got a heck of a lot better
We know that one of the major features a lot of you love about Kiln is its code review UI. While we generally really like the review system, we felt that there were a few key weaknesses we wanted to address:
- Having a review with multiple users is hard. Kiln 2.3 and earlier suggested you create separate reviews for each person you wanted to involve. This made having a single coherent conversation with multiple developers unintuitive. While multideveloper reviews are rare at Fog Creek, we’ve found that they’re extremely common for a lot of our customers.
- Users who had a lot of code reviews frequently could get lost in what was going—especially if they had multiple code reviews on the same changeset. Unless users thought to give the reviews unique titles at creation time, they’d end up with a pile of reviews with nearly identical titles.
- Frequently, a review would spark a need for making a case in FogBugz. For example, a given line of code might not be wrong, but might make a developer realize that syadmin action was required. To make a case, you’d have to leave Kiln, go to FogBugz, make a case, tie it to the review, and then go back to Kiln. This was annoying.
- Customers had trouble figuring out how to use the UI. Buttons that controlled the review were at the top, but the controls for adding comments were all at the bottom. This split made it easy for new users to get confused by the system.
We tried to address all these issues with a brand-new UI:
First, all of the actions you can use to modify a review are all located right at the bottom. We’ve tried to make it clear how to resolve and comment on a review, and made it clearer that you can resolve a review with a message.
Second, we’ve made it easy to make a case right from any comment in a review. If you see something that doesn’t really need to get fixed as part of a review, but that you realized was a bug that needed to get addressed elsewhere, or inspired a great feature idea, just click the “Make Case” button on the relevant comment. We’ll make a case in FogBugz and immediately tie it to the review, making it easy for you to keep everything tightly linked together.
Third, we made it easy to retitle a review at any point: just click the title. If you have a pile of nearly identical reviews, just give them better names to help disambiguate them.
Finally, we’ve made it much easier to have lots of developers contribute to a review by making it clearer that a review can be assigned to anyone, and by autosubscribing anyone who has seen a review. We’ve found this system makes it feasible for lots of developers to actually stay on-top of a review, while leaving the old one-on-one style in tact for those who like the current way things work, and making sure that some developer ultimately has responsibility for resolving the code review.
While we’ve been enjoying this new behavior internally, it’s brand-new, and a change from how Kiln’s traditionally worked, so we’d love your feedback. If you hate it, we’ll kill it. If you have great suggestions, we’ll add them. Just let us know.
Diffs are way more powerful
At the center of every source control system are diffs. They’re the be-all end-all at the end of the day: if the system can’t tell you what’s changed, then it’s not really doing you any good.
For Kiln 2.4, we dramatically increased the power of our diff system. You can now change tab size, toggle whether to show whitespace, ignore whitespace changes completely, and finally, in answer to one of our most-requested features, display diffs side-by-side.
You can learn all about Kiln’s amazing diff controls on our StackExchange.
File histories now show a DAG
Everyone knows that their repository is a DAG, but what’s not always well exposed is that your file history is a DAG, too.
Beginning in Kiln 2.4, we expose that DAG in the file history view, making it much clearer what the actual history of your file was.
And a lot more
Those are five of the things we're most proud of, but check out our full release notes if you're curious to take a look at everything we just shipped. Some of the things I didn't get a chance to talk about are:
- You can tell Kiln to ignore files
- Kiln now supports Mercurial bookmarks
- Massive bfiles improvements
- Search improvements
Plus, in case you missed it, we’ve added these features to Kiln since the new year:
- Changesets related to a case are shown inline in FogBugz
- Kiln allows jumping to the electric DAG directly from a given changeset
- Reviews are now repository-independent
- Reviews can be assigned to virtual users
- Review comments can be threaded
- And more!
We’re very excited about where Kiln is going to go this year. We really believe that having such a rapid release cycle will make us much better able to respond to your bugs and feature requests, and ensure that you get a steady stream of improvements throughout the year.
If you have any questions or concerns about any of this, don’t hesitate to contact us. We’re always listening.