Archive for the ‘Kiln’ Category

11 Things You Didn’t Know About FogBugz and Kiln Integration

February 5th, 2015 by Derrick Miller

FogBugz is great at keeping a full audit history of changes in a case. It ensures the information you need doesn’t get lost. Kiln is great at keeping your source code centrally located. It’s also great at allowing you access to the full audit history of your code. These are two distinct audit histories. However, often a case is a bug or a feature request which means that code is written and pushed to Kiln to solve it. So our FogBugz and Kiln integration helps you to see both of these histories in one place: the FogBugz case.

Below, we’ll talk about the benefits of this integration, how you can quickly integrate the two products yourself, and a few tasty bonus tips to finish off.

What’s so great about FogBugz and Kiln integration?

It all starts with a case. A case has full audit history; any change, any comment, anything. Kiln has a full audit history as well; who committed, who pushed, who authored – and when. Since a case represents a feature, a bug, or any other category of work that affects code – why not merge these histories upon a FogBugz case to see how your code changes over time in relation to the case?

That’s what Kiln set out to do. It gives you a natural history of events on your FogBugz case of your changeset history in Kiln. Voilà – a full-circle single-view audit history.

While viewing a FogBugz case that has associated changesets in Kiln, you will see several important pieces of information:

1. The changeset between your case edits and/or emails
2. List of code reviews that include changesets associated to the case
3. Number of changesets associated to this case
4. Ability to create a code review
5. List of changesets associated to the case
6. The short changeset ID
7. The author of the changeset
8. The time the changeset was committed
9. The repository the changeset is in, and if the changeset shows up in any related repositories
10. List of tags on this changeset
11. The changeset’s commit message

case with changesets review numbered

Complete the Integration

All you need to complete the integration is a FogBugz case number. Include your case number in the changeset’s commit message and Kiln will automatically link the history with the case.

git commit -m "fixing bug 495 - making todo item show strikethrough formatting when checked off"

Or, associate a case to a changeset after you have pushed to Kiln.
kiln add a case

We took this a step further and added Kiln Code Reviews to the case as well. This way you can see not only the full case history and associated changeset commit history, but the associated Code Reviews to the changesets on the case. It’s all there, in one historical view.

A Few More Tricks

  • If a case has changesets associated with it, then you can create a code review on those changesets directly from the FogBugz Case. Click “Request Review”, then click the “Review” button on any of the changesets. One stop shopping.
    add code review from case
  • If you mention the review number in your case comments, then FogBugz will automatically link to your Code Review.
  • Similarly, if you put the short changeset ID in your case comment, then FogBugz will automatically link a Kiln search for that changeset ID.
    changeset and review linkage
  • In Kiln, while viewing a changeset, not only can you add a case to the changeset, but you can also see a list of the cases already associated to the changeset, or remove the association.
  • FogBugz, when displaying the changesets on the case, will respect your Kiln permissions. If someone can view a case, but doesn’t have access to the repository in Kiln, then they will not see the Kiln changeset and commit message.

When a changeset from Kiln is associated with a FogBugz case, you get the full circle history of your bugs or features. The easiest way to get started is to click “Add a case” on any changeset in Kiln today and input a case number!

Stop More Bugs with our Code Review Checklist

January 8th, 2015 by Gareth Wilson

In our blog about effective code reviews, we recommended the use of a checklist. Checklists are a great tool in code reviews – they ensure that reviews are consistently performed throughout your team. They’re also a handy way to ensure that common issues are identified and resolved.
100_blue (1)
Research by the Software Engineering Institute suggests that programmers make 15-20 common mistakes. So by adding such mistakes to a checklist, you can make sure that you spot them whenever they occur and help drive them out over time.

To get you started with a checklist, here’s a list of typical items:

Code Review Checklist


  • Does the code work? Does it perform its intended function, the logic is correct etc.
  • Is all the code easily understood?
  • Does it conform to your agreed coding conventions? These will usually cover location of braces, variable and function names, line length, indentations, formatting, and comments.
  • Is there any redundant or duplicate code?
  • Is the code as modular as possible?
  • Can any global variables be replaced?
  • Is there any commented out code?
  • Do loops have a set length and correct termination conditions?
  • Can any of the code be replaced with library functions?
  • Can any logging or debugging code be removed?


  • Are all data inputs checked (for the correct type, length, format, and range) and encoded?
  • Where third-party utilities are used, are returning errors being caught?
  • Are output values checked and encoded?
  • Are invalid parameter values handled?


    integration testing

  • Do comments exist and describe the intent of the code?
  • Are all functions commented?
  • Is any unusual behavior or edge-case handling described?
  • Is the use and function of third-party libraries documented?
  • Are data structures and units of measurement explained?
  • Is there any incomplete code? If so, should it be removed or flagged with a suitable marker like ‘TODO’?


  • Is the code testable? i.e. don’t add too many or hide dependencies, unable to initialize objects, test frameworks can use methods etc.
  • Do tests exist and are they comprehensive? i.e. has at least your agreed on code coverage.
  • Do unit tests actually test that the code is performing the intended functionality?
  • Are arrays checked for ‘out-of-bound’ errors?
  • Could any test code be replaced with the use of an existing API?

You’ll also want to add to this checklist any language-specific issues that can cause problems.

The checklist is deliberately not exhaustive of all issues that can arise. You don’t want a checklist, which is so long no-one ever uses it. It’s better to just cover the common issues.

Optimize Your Checklist

Using the checklist as a starting point, you should optimize it for your specific use-case. A great way to do this is to get your team to note the issues that arise during code reviews for a short time. With this data, you’ll be able to identify your team’s common mistakes, which you can then build into a custom checklist. Be sure to remove any items that don’t come up (you may wish to keep rarely occurring, yet critical items such as security related issues).

Get Buy-in and Keep It Up To Date

As a general rule, any items on the checklist should be specific and, if possible, something you can make a binary decision about. This helps to avoid inconsistency in judgments. It is also a good idea to share the list with your team and get their agreement on its content. Make sure to review the checklist periodically too, to check that each item is still relevant.

Armed with a great checklist, you can raise the number of defects you detect during code reviews. This will help you to drive up coding standards and avoid inconsistent code review quality.

To learn more about code reviews at Fog Creek, check out the following video:

Effective Code Reviews – 9 Tips from a Converted Skeptic

November 17th, 2014 by Gareth Wilson

I knew the theory. Code reviews help to:

  • Catch bugs
  • Ensure code is readable and maintainable
  • Spread knowledge of the code base throughout the team
  • Get new people up to speed with the ways of working
  • Expose everyone to different approaches

Or, they’re just a giant waste of time. At least, that was my first impression of code reviews.

I was the new guy, a recent grad, developing plugins for a software company in London.

Over time I had to submit blocks of identical or similar code. They would get reviewed by the same poor, put upon guy (“he’s the best at it” my manager told me. No good deed…). Yet each review would come back picking at something different. It seemed needlessly picky and arbitrary.

Worse still, reviews would take days, if not weeks. By the time I got my code back I could hardly remember writing it. It wasn’t the guy’s fault. He’d asked for a senior dev, but had gotten me. He was sick of dealing with the issues every inexperienced developer makes, and code reviews were his way of exorcising that frustration.

Add to this the time lost in syncing the different branches, the context-switching… I was not a fan, nor were the rest of the team and it showed.

Skip forward a few years though and I find myself nodding along whilst reading a tweet quoting Jeff Atwood:

“Peer code reviews are the single biggest thing you can do to improve your code.”

What I had come to appreciate in the intervening years is that it wasn’t that code reviews were bad. Code reviews done badly were. And boy, had we been doing them badly.

I had learned this the hard way. And it certainly didn’t happen over night. Although on reflection, code reviews have saved me from more than a few embarrassing, build-breaking code changes! But after I had worked elsewhere, I gained experience of different and better ways of working. This gave me opportunity to see first-hand the benefits of code reviews that I had dismissed before. So now I consider myself a converted skeptic.

So that you can avoid such pains, check out our video and then read on for tips that will skip you straight to effective code reviews.

9 Code Review Tips

For everyone:

  • Review the right things, let tools to do the rest

    You don’t need to argue over code style and formatting issues. There are plenty of tools which can consistently highlight those things. Ensuring that the code is correct, understandable and maintainable is what’s important. Sure, style and formatting form part of that, but you should let the tool be the one to point out those things.

  • Everyone should code review

    Some people are better at it than others. The more experienced may well spot more bugs, and that’s important. But more important is maintaining a positive attitude to code review in general and that means avoiding any ‘Us vs. Them’ attitude, or making reviewing code burdensome for someone.

  • Review all code

    No code is too short or too simple. If you review everything then nothing gets missed. What’s more, it makes it part of the process, a habit and not an after thought.

  • Adopt a positive attitude

    This is just as important for reviewers as well as submitters. Code reviews are not the time to get all alpha and exert your coding prowess. Nor do you need to get defensive. Go in to it with a positive attitude of constructive criticism and you can build trust around the process.

For reviewers:


  • Code review often and for short sessions

    The effectiveness of your reviews decreases after around an hour. So putting off reviews and doing them in one almighty session doesn’t help anybody. Set aside time throughout your day to coincide with breaks, so as not to disrupt your own flow and help form a habit. Your colleagues will thank you for it. Waiting can be frustrating and they can resolve issues quicker whilst the code is still fresh in their heads.

  • It’s OK to say “It’s all good”

    Don’t get picky, you don’t have to find an issue in every review.

  • Use a checklist

    Code review checklists ensure consistency – they make sure everyone is covering what’s important and common mistakes.

For submitters:

  • Keep the code short

    Beyond 200 lines and the effectiveness of a review drops significantly. By the time you’re at more than 400 they become almost pointless.

  • Provide context

    Link to any related tickets, or the spec. There are code review tools like Kiln that can help with that. Provide short, but useful commit messages and plenty of comments throughout your code. It’ll help the reviewer and you’ll get fewer issues coming back.


Register Now for ‘Code Reviews in Kiln’ Webinar

Join us for our next live ‘Code Reviews in Kiln’ webinar. This webinar will help first time or novice users learn the basics of Code Reviews in Kiln.

We’ll cover:

  • What are Code Reviews
  • Why use Code Reviews
  • When use Code Reviews
  • What to look for during Code Reviews
  • Creating a Code Review
  • Commenting and Replying on a Code Review
  • Working with Existing Code Reviews
  • Code Review Workflow

Secure your spot, register now.

Link Git and Mercurial Changesets to Trello with Kiln

September 15th, 2014 by Stephen Asbury

If you have ever used Trello, then you know it is an awesome tool for project planning and management. We use it a lot at Fog Creek, including in the Kiln team. When we are doing work that relates to a card, we thought it would be nice if we could attach the card to a changeset in Kiln. So that is what we did. Announcing Project WolfEagle! Now you can connect Trello Cards to your Kiln Changesets.


There are two main ways to add cards to a changeset. First, you can include a card in a commit message. This can be done by adding text of the form:

card: NjWA9NN5

to your card, or you can include the full URL for a card:

Second, when viewing a changeset in Kiln, you can manually add cards to this changeset by clicking “Attach a Card”.


Of course there are some security considerations. In order to search Trello you first have to authenticate your Kiln user to your Trello account by clicking “Connect to Trello” when viewing a changeset in Kiln. If you are already logged in to both, this is as simple as pressing “Connect to Trello” and “Allow” in the subsequent Trello authorization popup.


But wait, there’s more! When you attach a card to a changeset, we create an attachment on the card pointing back to it. That way you can see that you made the change in Trello. Even better, the Trello team will let you know that the attachment points to Kiln with a lovely icon.


Now some of you might be thinking, what if I add cards to my commit message before I authenticate with Trello? In that case, we give you an option in the changeset UI to fix the Trello attachment. But we only do that once.


So that’s it. We have created a simple integration between Kiln and Trello. Our code doesn’t go back in time, so if you had some card URLs on changesets from before, you will have to associate those cards manually. But we are looking out for you from now on. So go out there and do good work with the WolfEagle, because Kiln + Trello == Awesome! If you aren’t a Kiln user already, you can start your free trial today.

Kiln and Visual Studio: Different Gits, Same Commits

August 1st, 2014 by Jacob Krall

Did you know that Kiln works with Visual Studio? If you’re working on a project in Visual Studio, you can get the power of Kiln without a command prompt. Using an IDE means never having to say Alt+Tab!

You will need to have a Kiln account to do this. If you haven’t already, sign up for Kiln.

Start A New Repository

First, create an empty repository in Kiln. On your Project page, click “New Repository” and give your project a memorable name. I picked “Enterprise Hello World”, but it’s only a code name, until I can think of a better one:

01 New Repository

On the empty repository page, choose “Git”:

02 Git mode

Select “HTTP” under “Starting a New Project?“, and copy the URL listed there:


In Visual Studio, open your project and select FILE > Add to Source Control to create a Git repository on your local machine. (I’m not sure why MICROSOFT wants us to YELL the names of MENUS. It’s not in the HUMAN INTERFACE GUIDELINES. It seems A LITTLE UNNATURAL, even if it can be configured under Tools > Options > [at Environment, General] .)

Open Team Explorer. (It’s under the VIEW menu. Don’t forget to yell “VIEW TEAM EXPLORER!!!” when you choose it. Surprisingly, that is in the Human Interface Guidelines.)

Click “Unsynced Commits”:

04 Unsynced Commits

This will give you a text box in which to gently deposit the repository URL you copied:

05 Publish to Remote Repository

Click “Publish”; Visual Studio will push a single commit to the repository, which creates .gitIgnore and .gitAttribute files, just for you. And everyone else on your project, I guess, since it’s now published in Kiln:

06 Pushed defaults

Write the first revision of your code. (You’re on your own for this part.)

To add your changes, open the Changes pane in Team Explorer:

07 GOTO Changes

(You can also click the “Changes” button from the Team Explorer Home pane.)

Type in a descriptive commit message:

08 Initial Commit
You can even
link to FogBugz cases or link to existing Kiln code reviews in your commit message.

Visual Studio will commit your changes locally. To share your changes with Kiln, go back to the Unsynced Commits pane by clicking the “Sync” link:

09 Committed

Click the “Sync” button on this pane, and Visual Studio will automatically merge your changes with any changes upstream, then publish your changes to Kiln:

10 Sync
Pro tip: to avoid having to Sync as a separate step, there is a dropdown next to the Commit button that lets you choose “Commit and Sync” in one operation.

All done! Your project is now synchronized, and you can continue to use Team Explorer to synchronize with Kiln.

Here’s what the push event looks like in the Kiln home page:

11 Done - Activity Feed

Clone An Existing Repository

If someone has already followed the steps above to create a repository, and you want to start working with them, you can do that too. It’s only fair.

Go to the repository in Kiln and make sure you are in Git mode. Select “HTTP” and click the clipboard icon to copy the URL:

13 Clone URL

In Visual Studio, open Team Explorer. (It’s under the menu formerly known as “VIEW!!!!!1111eleven!1″.) Click “Connect to Team Projects”:

12 Connect to Team Projects
Under “Local Git Repositories”, choose “Clone” and paste in the URL you copied from Kiln:

14 Connect

Click the Clone button. The repository will be copied to your local machine, and appear in Team Explorer. Go to the Team Explorer Home and double-click the solution file:

15 Open Solution

Visual Studio will open the solution. Your project is now synchronized, and you can continue to use Team Explorer to collaborate with your team via Kiln.

Now you have Visual Studio’s powerful Git client interacting with Kiln’s professionally-operated Git engine. Kiln is free for 30 days!

Fog Creek and Heartbleed

April 10th, 2014 by Mendy Berkowitz

Along with the rest of the internet, Fog Creek has been reacting to the Heartbleed vulnerability which was discovered this Monday.

TL;DR: FogBugz and Kiln On Demand, Copilot and the Fog Creek website were not vulnerable. Trello was vulnerable and has been remediated.

Fog Creek handles SSL connections at the load balancers in front of the application servers. The load balancers for FogBugz and Kiln On Demand, Copilot and the website are using the 0.9.8 branch of OpenSSL. This version does not have the newer heartbeat extension and is therefore not vulnerable to Heartbleed. None of your data on,, or has been exposed to the Heartbleed vulnerability.

The load balancers for Trello were using the 1.0.1 branch of OpenSSL and were vulnerable. We have upgraded OpenSSL and replaced the Trello certificates. More details and important recommended steps for all users are available in a post on the Trello blog.

We have also reviewed our vendors (for things like this blog) to ensure that our other SSL certificates were not potentially compromised. Fortunately we have not had to replace any other certificates.

If you have configured web hooks in your Kiln On Demand account, we recommend that you verify that the target servers have not been affected. If you use one of the pre-configured types, or your custom web hook uses HTTPS, the data sent to that external service may be at risk. We do not however, send any of your Kiln login credentials, so they are safe.

We take the security of your data seriously. We are committed to protecting it and to maintaining clear and open communication with you. If you have any questions, comments or concerns please contact us.

The Kiln Bottleneck

April 3rd, 2014 by Jacob Krall

Early in February, one of our Kiln On Demand customers sent us an email to let us know that Git clones were taking much longer than before. Our stellar support engineers started measuring Git transfer times from their own personal accounts, and confirmed that Kiln clones were being sluggish. We didn’t know what the problem was, and since it wasn’t completely preventing the clones from succeeding, we prioritized further investigation lower than we should have.

On Friday, March 7, another customer reported the same issue and wanted to know if we were throttling their connection. Our existing monitoring showed all services performing nominally, especially after the Kiln SSH server resource utilization fix in Kiln 3.0.115 had been released, so we were still a bit puzzled. I started writing a little PowerShell script I called timeit.ps1 to measure the time it took to run git clone and hg clone against the various distributed services inside Kiln. (Unlike Trello’s codenames, mine are boring and vaguely descriptive.) I ran timeit.ps1 against my local machine, and saw nothing unusual.

Kiln DVCS Hosting Infrastructure

Here are the endpoints that timeit.ps1 attempts to clone from; once with Git and once with Mercurial.

HAProxy, IIS, and Apache on the web side; HAProxy, Tesseract and KilnSSH on the SSH side.

HAProxy terminates HTTPS traffic and sends the request on to an IIS server.

IIS authenticates the git/hg request and forwards it to Apache on the backend server that holds the requested repository.

Apache hosts the process that actually performs the git/hg transfer.

HAProxy forwards all SSH packets, untouched, to a Tesseract server.

Tesseract reads the SSH traffic and forwards it to KilnSSH on the backend server that holds the requested repository.

KilnSSH authenticates and performs the git/hg transfer.

Interesting Problems Happen At Scale

There are very few differences between my local development install of Kiln and the live Kiln On Demand service. One particularly important difference is that Kiln On Demand serves real customers, while my laptop is dedicated to just one user (me). Since I couldn’t reproduce the problem on my local machine, but our support engineers and customers could see it every day, I knew the problem had to be something environmental. Monday morning, I tweaked timeit.ps1 to run against any Kiln instance, and pointed it at my personal Kiln On Demand account. By the end of the day on Monday, I shared this compelling graph with the rest of the team in chat.

The public endpoints are much slower than the endpoints immediately behind them

Bingo. Our load balancer, HAProxy, was doubling the clone speed. Kiln QA engineer Andre confirmed from his home in Vancouver, B.C. by running timeit.ps1, he got the same exact shape on his graph. It had to be the load balancer!

By Tuesday morning, our System Administrators (whom I had otherwise forgotten about) had already formulated a plan to add power to the HAProxy machine. A Puppet script was written and run against the staging environment for testing on Tuesday. The process was repeated on our internal Kiln instance Wednesday morning for dogfooding and internal testing all day. That Wednesday night’s maintenance successfully switched the customer-facing servers to the new configuration, and the results were immediate and drastic:


Mercurial KilnSSH clones are somehow slower than its caller, Tesseract. This is a strange artifact of the measurement.

Richard, our support engineer in London, had a monitoring task set up that ran a git clone via public SSH. His graph confirmed that the HAProxy maintenance had an immediate and drastic effect. The variance dropped dramatically, making a smooth, placid lake out of what was once a spiky mountain range:

A graph showing Git clone becoming faster and less variant.

Lessons Learned

The scientific method is insanely effective. Formulate a hypothesis, design an experiment, run the experiment, and analyze the results. Then it is often obvious what you need to do.

Software is invisible. You can only observe its behavior indirectly, by measuring it. That means you can’t see what you don’t measure.

Your customers know when your application has a performance problem. If you can’t explain it, you need to dig in and figure it out.

Next Steps

timeit.ps1 was a one-off test script. It only runs in Windows, and is not very easy to use. We are adding automated measurement of DVCS metrics to our monitoring systems.

Start a free trial of Kiln and enjoy the faster Git and Mercurial clones today!

What’s new in Kiln? AppVeyor web hook!

October 17th, 2013 by Kevin Gessner

Do you use AppVeyor to build and deploy your .NET projects?  If so, you’re in luck: Kiln’s web hooks now connect to AppVeyor!

AppVeyor web hook

AppVeyor can pull your code directly from Kiln.  Once you’ve created your project in AppVeyor, you can trigger a build manually, or set up the new web hook to trigger a build on every push.

AppVeyor builds

Building .NET projects has never been easier!

The AppVeyor web hook is available in Kiln 3.0.90 and higher.  Want to see Kiln integrate with another service?  Let us know!

Introducing name association in Kiln

October 2nd, 2013 by Hao Lian

My first Hotmail account was “” because at the time “hao” and “haolian” were taken and I didn’t know any better than to add an ungainly two in the middle of my name.

Then when I discovered IRC my mom, bless her heart, told me I could have any handle I wanted as long as it didn’t contain my real name. (I was 14 at the time, and Edward Snowden was 21.) I wanted to keep being hao2lian, but I also wanted my mom to be happy. So I conceded.

Now I had two identities. And I was hooked, hooked on coming up with better and better nicknames for myself until I had to start tracking all my usernames in a text file, which by the end of the aughts included multiple Yahoo and Gmail email accounts. Thank goodness for Dropbox when it finally came along.

So it’s not surprising that name and email association is one of the hotly requested features for Kiln. We took a while, but we finally got around to it. As part of his last summer’s Kiln internship, Josh Cooper spruced up the changeset page with this nifty link, which you’ll see if you’re an administrator on your Kiln account:

The name association popup

Were you to click on the link and choose a Kiln user

A successful name association

you will have taught Kiln that the username maps to that Kiln user! From that day forward, all commits with that username will become linked to that person in your Kiln account. Kiln beams at you. Armed with this new information, it can connect up your search results, revset filtering, review data, and more to the right Kiln account. All for you, and your ever-mercurial internet identity.

Hao Lian is a programmer on the Kiln team. Did you know about the ArtisanVideos subreddit?

Introducing the Kiln Command Line Tool for Git

September 25th, 2013 by Benjamin Pollack

We made Kiln into the best enterprise Git hosting tool in March, and we’ve been happily shipping Git and related utilities as part of the Kiln Client Tools since then. But there was always one component missing: an equivalent of the hg kiln command-line tool.

We know that many users prefer to use GUIs, but for those of us who are wedded to our command lines, having a quick and easy way to work with Kiln without leaving the keyboard is a godsend. From Mercurial, this is pretty easy: want to see a list of related repositories? That’s just hg kiln -t. Want to make a new repository to push your changes to? A quick hg kiln -n MyBranch and you’re good. Want to see a given file annotated with Kiln’s multilevel line annotations? hg kiln -a FooBar/Baz.cs and your browser pops up before you have a chance to spill your coffee. But since hg kiln was implemented as a Mercurial extension, Git users were left out in the cold, with no equivalent functionality.

No more. Now, Git users now have the git kiln command to access equivalent functionality. Want to see related repositories? That’s a simple git kiln related. You can view commits in Kiln via git kiln show (which takes everything Git understands, including even weird things like HEAD^^), where you can open reviews, link bugs, or view them in the Electric DAG. You can create branches in Kiln via the simple git kiln create-branch command. You can even do something your Mercurial colleagues can’t yet do: look up the Mercurial changeset that corresponds to the a Git commit, with the handy git kiln hg-sha command. There’s a lot more built-in, too; you can get the full details via git kiln help.

While we’re only distributing this first release of git kiln with our Windows Kiln Client tools, git kiln already runs on Mac and Linux. We’ll be working in the coming weeks to provide an easy way for Mac and Linux users to install it. In the meantime, git kiln is fully open-source and easy to build with Go, so feel free to take a look, play with it, and even submit a pull request if you’re so motivated.

Looking for more?

Visit the Archives or subscribe via RSS.