Atlassian Stashを使用したコードレビュープロセス

みなさんこんにちは! そこで、当社はHabréでブログを開始することにしました(最終的に、他の人の記事を読むことは永遠ではありません)。 会社概要では、私たちが何をしているかを見ることができます。 近い将来、配信サービスやiOSアプリケーションのテストビルドのサポートからIISソフトウェア管理まで、幅広いトピックに関する一連の記事が注目されます。 そして、最初の出版物はAtlassian Stashに捧げられています。







現在、 ハブではAtlassian Stashに関する情報はほとんどありません(インストールトピックに関する1つのお知らせと1つの記事のみ )。 実際、このツールは素晴らしいものであり、アトラシアンスタック全体を使用する際に検討する価値があります。 それが何であるか、そしてこのことを開発プロセスにどのように追加できるかを伝えたい。



少しの背景-新しい顧客があり、開発用のインフラストラクチャをゼロから構築することができます。 私はすぐに「すべてが正しい」ことをしたかった-git / CI /コードレビューなど 誰もがコードレビューが重要かつ必要であることに同意しているようですが、誰もがそれを使用しているわけではありません。 ワークフローのどこかで、誰かがコミットコード、またはその他の口頭/書面で合意された制限を確認するまで、タスクを解決することは禁止されています。 しかし、技術的な観点からプロセスをより制御したかったのです。



コードレビューのサポート/サポート付きのソリューションから、 TFSAtlassian StashGithubGerrit 、JetBrainsの新しいUpsourceが思い浮かびました。



それぞれについて簡単に:

  1. .NETとWindowsだけではないので、TFSは消えます(そして、いずれにせよ、gitを使用するとレビューはそこで機能しません)。
  2. Github-すべてが明確で、プライベートリポジトリまたはGithub Enterpriseのスタンドアロンバージョンを提供します。 プルリクエストリクエストとレビュー-github.com/jquery/jquery/pull/1241/files 主な論点は、プライベートリポジトリに対するものですが、プライベートホスティングに対するものです。
  3. Gerrit-コードレビュー専用に作られた、すべてがクールですが、まだどこかでリポジトリをホストする必要があります。 また、SVNに慣れている人にとっては、これを使用するのは少し難しいかもしれません。
  4. アップソース-Gerritと同じ主張-リポジトリの管理用ではなく、コードレビュー専用のツール。 はい、選択時には存在しませんでした。
  5. Stashは、アトラシアンの比較的新しい製品です。 ミニチュアのgithubの一種-リポジトリをホスト/管理し、Jira / Bambooと統合し、クラウドではなく、プールリクエスト、フォーク、そして最も重要なことを行うことができます。 一般的に言えば、Crucible(元Fisheye)もありますが、それはやや時代遅れで、リポジトリ自体を管理しません。


最終的に、Stashにとどまることにしました。 インストール/構成/統合は、すべてのアトラシアン製品に典型的なものであり、それについて詳しく説明することは意味がありません。 gitのみがサポートされ、コードレビュー要件はプールリクエストを通じて実装されます。また、リクエストを保留できるように、最小ハードウェア/成功ビルドの数を構成することができます。 Bambooと統合する場合、たとえば、このブランチの単体テストを破らないようにするために、ビルドが必要です。 どうやら、成功したビルドの数は、個別のビルドで個別に実行されるパフォーマンス(または比較的長い時間がかかるため、コミットごとに実行されない他のテスト)がある場合にのみ意味があります。 さて、私は別のアプリケーションを思いつきませんでした。







Gitflow


ブランチを適切に整理し、後でそれが耐え難いほど苦痛にならないように、それはすでに長い間考えられていたので、ワークフロー自体に留まらない-私はおおよそのアルゴリズムを書くだけだ:



  1. すべての機能/バグ修正は別のブランチにある必要があります。 さて、ここではすべてがシンプルです-Stashはgitリポジトリ自体を管理し、ブランチはもちろんサポートされており、ブランチはJiraの課題ウィンドウから直接作成できます。
  2. 開発者はこのブランチにコードをプッシュします。
  3. Bambooが新しいブランチを自動的に選択するカスタマイズされたビルドを持っている場合、Stashはビルドが収集されたことを確認します。
  4. 開発者はPRを作成し、レビュー担当者を任命します。 残念ながら、リストからランダムに手で指名することは不可能です。
  5. レビュー担当者は、メールで通知を受け取り、変更点(標準の差分または2パネル比較)を確認し、コメントを残すことができます。 実際には、チームのほぼ全員がレビュアーに配置され、編集ボタンがコードに触れた人、またはプロジェクトの影響を受けた部分に最も精通している人が承認ボタンをクリックすることがわかります。
  6. 開発者はアップグレードを待っており、グリーンビルドが存在する場合、プルリクエストを含めて問題を解決できます。


このプロセスを示すアトラシアンのビデオ:







すべてがどのように緊密に統合されているかを示していますが、このすべて(たとえば、[レビューの開始]ボタン)が機能しませんでした。 バージョンに問題がある可能性があります。



最後に、有用な機能の小さな絞り/可能な質問への回答





All Articles