Code Review Process with Atlassian Stash

Hello! So our company decided to start a blog on Habré (after all, it’s not forever to read other people's articles). In the company profile you can see what we do. 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, there is practically no information on the Atlassian Stash (just one announcement and one article on the topic of installation). Although the tool is, in fact, excellent, 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 small background - we have a new customer and the opportunity to build the infrastructure for development from scratch. I immediately wanted to do “everything is right” - git / CI / code-review, etc. Everyone seems to agree that the code-review is important and necessary, meanwhile, not everyone uses it, and if they do, they mostly use a post-factum version - commit to a trunk, someone later looked. Somewhere on the workflow it is forbidden to rezolvit task, until someone looked at the commit code, well, or other oral / written-agreed restrictions. 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 , the new Upsource from JetBrains.
')
Briefly for each:

1. We do not only have .NET and Windows, so TFS disappears (and in any case, the review does not work there when using git).
2. Github - everything is clear, gives private repositories or standalone version of Github Enterprise. An example of pull-request and review is github.com/jquery/jquery/pull/1241/files . The main argument against private repositories is private hosting.
3. Gerrit - made specifically for code review, everything is cool, but we still have to host the repositories ourselves. In addition, the use can be somewhat difficult for people who are used to SVN.
4. Upsource is the same complaint as Gerrit is 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 sort of github in miniature - hosting / management repositories, integrates with Jira / Bamboo, allows you to do pull-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 stop at Stash. Installation / configuration / integration is typical for all Atlassian products, there is no particular point in dwelling 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 apruv / successful builds so that you can restart the requester. Builds are needed when integrating with Bamboo - for example, to ensure that nobody broke unit tests in this brunch. Apparently, the number of successful builds makes sense only if there are separate performance runs (or others that take a relatively long time and therefore are not executed for each commit) tests in a separate build. Well, I have not come up with another use.

Gitflow

How to organize branches correctly, so that later it would not be excruciatingly painful, has long been invented before us, so I won’t stop at the workflow itself - I’ll just write an approximate algorithm:

1. All features / bugfixes must be in separate branches. Well, everything is simple here - Stash manages the git repositories himself, the branches are, of course, supported, and the branches can be created directly from the issue window in Jira.
2. The developer is pushing code in this brunch.
3. If Bamboo has a customized build that automatically picks up new branches, Stash finds out that the build is ready.
4. The developer creates a PR and assigns reviewers. Appoints hands, randomly from the list, alas, is impossible.
5. The reviewer receives a notification by mail, watches the changes (standard diff or two-pane comparison), can leave comments and so on. In practice, it turns out that almost the entire team is placed on the revision controllers, and the people whose code has been touched by the edits, or those who are most familiar with the affected part of the project, click on the Approve button.
6. The developer waits for the appruva and, if there is a green build, can pull a request and kill the task.

Video from Atlassian with a demonstration of this process:



It shows how everything integrates coolly, but some of this (for example, the Start Review button) did not work for us. Perhaps a problem with the version.

Finally, a slight 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 branches without creating pull-requests.
• Email notifications, of course. About new pull-requests, new comments to created pull-requests, etc.
• There is a paid plugin Notifyr, which allows you to mark the repository as a favorite and receive notifications about all the buttons in it.
• It supports personal user repositories, the rights to which are controlled by the user.
• You can make forks. Auto-sync branches are also supported. A fly in the ointment - if you want to use the development model, where everyone works in their forks, and then they make a pull-request to the main repository, then you will not be able to add a dependency on the green builds in Bamboo - he simply does not know about the existence of forks.
• In the 3.x version there were likes for comments. 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 branch. In fact, the direct merge of branches, for example, to develop to bypass Stash, all the same, is forbidden in words, because merge is a feature of git. You can, of course, give permissions to a branch only to the one responsible for the merge user, 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 the Stash User checkbox - this can be useful if you have many users in Jira, and the Stash license is supported by, say, only 50 users.
• Enough voracious in terms of memory consumption.
• Despite the fact that both Stash and Bitbucket products are from the same company, the code-base is different, so the presence of a feature in one of them does not mean the same in the other.