Code Review Process with Atlassian Stash

Hello! So our company decided to start a blog on Habré (in the end, it’s not forever to read other people's articles). In the company profile you can see what we are doing. In the near future we will bring to your attention a series of articles on a wide range of topics: from distribution services and support for test builds of iOS applications to IIS software management. And our first publication is devoted to Atlassian Stash.

For the current day, almost no information about Atlassian Stash is practically absent on the hub (just one announcement and one article on the installation topic). Although the tool is, in fact, wonderful, and definitely worth considering when using the entire Atlassian stack. I want to tell what it is and how this thing can be added to the development process.

A little background - we have a new customer and the ability to build infrastructure for development from scratch. I immediately wanted to do “everything right” - git / CI / code-review, etc. Everyone seems to agree that code-review is important and necessary, yet not everyone uses it, but if they use it, it’s basically a kind of ex-post version - they committed to the trunk, someone later looked. Somewhere on the workflow it is forbidden to resolve the task until someone has looked at the commit code, well, or other verbally / written-agreed restrictions. But we wanted to make the process more controlled from a technical point of view.

From solutions for / with support for code-review came to mind: TFS , Atlassian Stash , Github , Gerrit , newUpsource from JetBrains.

Briefly for each:

1. We have not only .NET and Windows, so TFS disappears (and in any case, the review does not work there if git is used).
2. Github - everything is clear, gives private repositories or standalone version of Github Enterprise. Pull request request and review - github.com/jquery/jquery/pull/1241/files . The main argument is against private repositories, but private hosting.
3. Gerrit - made specifically for code review, everything is cool, but we still need to host the repositories ourselves somewhere. Also, using it can be a little tricky for people who are used to SVN.
4. Upsource - same claim as Gerrit - a tool exclusively for Code-Review, not for managing repositories. Yes, and it did not exist at the time of choice.
5. Stash is a relatively new product from Atlassian. A kind of github in miniature - hosts / manages repositories, integrates with Jira / Bamboo, allows you to do pool requests, forks, and most importantly - not in the cloud. Generally speaking, they also have Crucible (ex-Fisheye), but it is somewhat outdated and does not manage repositories by itself.

In the end, we decided to stay at Stash. Installation / configuration / integration is typical for all Atlassian products, it makes no sense to dwell on it. Only git is supported, and the code-review requirement is implemented through pool requests, and it is possible to configure the number of minimum hardware / successful builds so that the request can be held back. Builds are needed when integrated with Bamboo - for example, to ensure that no one breaks unit tests in this brunch. Apparently, the number of successful builds makes sense only if there are separately run performance (or others that take a relatively long time and therefore not run for each commit) tests in a separate build. Well, I did not come up with another application.

Gitflow

How to organize branches correctly, so that later it would not be excruciatingly painful, it’s been thought up for a long time already , so I won’t stop at workflow itself - I’ll just write an approximate algorithm:

1. All features / bug fixes should be in separate brunches. Well, everything is simple - Stash manages the git repositories itself, branches, of course, are supported, and branches can be created directly from the issue window in Jira.
2. The developer pushes the code into this brunch.
3. If Bamboo has a customized build that automatically picks up new brunches, Stash finds out that the build has gathered.
4. The developer creates a PR and appoints reviewers. Appoints with hands, randomly from the list, alas, is impossible.
5. The reviewer receives notification by mail, watches the changes (standard diff or two-panel comparison), can leave comments, and so on. In practice, it turns out that almost the entire team is placed in the reviewers, and the Approve button is clicked by people whose code has been touched by the edit, or who are most familiar with the affected part of the project.
6. The developer waits for an upgrade and, in the presence of a green build, can delay pull-request and enforce the task.

Atlassian video demonstrating this process:



It shows how everything integrates cool, but some of all this (for example, the Start Review button) did not work for us. There may be a problem with the version.

Finally, a small squeeze of useful features / answers to possible questions

• Supported protocols: HTTP / HTTPS and SSH. In the first case, password authentication, in the second - by key.
• Syntax highlighting.
• Ability to compare brunches without creating pull requests.
• Email notifications, of course. About new pull-requests, new comments on created pull-requests, etc.
• There is a paid Notifyr plugin that allows you to mark the repository as a favorite and receive notifications about all the push to it.
• It supports personal user repositories, the rights to which are controlled by the user.
• You can make forks. Auto-sync branches is also supported. Fly in the ointment - if we want to use a development model where everyone works in their forks, and then pull-request into the main repository, then we can’t add the dependency to the “green” builds in Bamboo - he simply does not know about the existence of forks.
• In the 3.x version, comments appeared. My personal opinion is that they have at least some practical value in the case of open-source (a very large and distributed team).
• It is impossible to prohibit (at least in version 2.x, there are already 3.x) direct commits (without pull-requests) in any brunch. In fact, direct merge branches, say, in develop, bypassing Stash, still have to be prohibited in words, since merge is a git feature. Of course, you can give the rights to the branch to only one user responsible for the merge, but this makes sense only in extremely rare cases.
• You can write hooks in Java and add them as plugins (for example, if you need to solve the problem from the previous paragraph).
• You can use the Jira / Crowd server as a User Directory. Each user individually can uncheck Stash User - this can be useful if you have a lot of users in Jira, and the Stash license supports, say, only 50 users.
• Voracious enough in terms of memory consumption.
• Despite the fact that both Stash and Bitbucket are products of the same company, the code-base is different for them, so the presence of some feature in one of them does not mean the presence of the same in the other.