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

現在、 ハブではAtlassian Stashに関する情報はほとんどありません(インストールトピックに関する1つのお知らせと1つの記事のみ )。 実際、このツールは素晴らしいものであり、アトラシアンスタック全体を使用する際に検討する価値があります。 それが何であるか、そしてこのことを開発プロセスにどのように追加できるかを伝えたい。
少しの背景-新しい顧客があり、開発用のインフラストラクチャをゼロから構築することができます。 私はすぐに「すべてが正しい」ことをしたかった-git / CI /コードレビューなど 誰もがコードレビューが重要かつ必要であることに同意しているようですが、誰もがそれを使用しているわけではありません。 ワークフローのどこかで、誰かがコミットコード、またはその他の口頭/書面で合意された制限を確認するまで、タスクを解決することは禁止されています。 しかし、技術的な観点からプロセスをより制御したかったのです。
コードレビューのサポート/サポート付きのソリューションから、 TFS 、 Atlassian Stash 、 Github 、 Gerrit 、JetBrainsの新しいUpsourceが思い浮かびました。
それぞれについて簡単に:
- .NETとWindowsだけではないので、TFSは消えます(そして、いずれにせよ、gitを使用するとレビューはそこで機能しません)。
- Github-すべてが明確で、プライベートリポジトリまたはGithub Enterpriseのスタンドアロンバージョンを提供します。 プルリクエストリクエストとレビュー-github.com/jquery/jquery/pull/1241/files 主な論点は、プライベートリポジトリに対するものですが、プライベートホスティングに対するものです。
- Gerrit-コードレビュー専用に作られた、すべてがクールですが、まだどこかでリポジトリをホストする必要があります。 また、SVNに慣れている人にとっては、これを使用するのは少し難しいかもしれません。
- アップソース-Gerritと同じ主張-リポジトリの管理用ではなく、コードレビュー専用のツール。 はい、選択時には存在しませんでした。
- Stashは、アトラシアンの比較的新しい製品です。 ミニチュアのgithubの一種-リポジトリをホスト/管理し、Jira / Bambooと統合し、クラウドではなく、プールリクエスト、フォーク、そして最も重要なことを行うことができます。 一般的に言えば、Crucible(元Fisheye)もありますが、それはやや時代遅れで、リポジトリ自体を管理しません。
最終的に、Stashにとどまることにしました。 インストール/構成/統合は、すべてのアトラシアン製品に典型的なものであり、それについて詳しく説明することは意味がありません。 gitのみがサポートされ、コードレビュー要件はプールリクエストを通じて実装されます。また、リクエストを保留できるように、最小ハードウェア/成功ビルドの数を構成することができます。 Bambooと統合する場合、たとえば、このブランチの単体テストを破らないようにするために、ビルドが必要です。 どうやら、成功したビルドの数は、個別のビルドで個別に実行されるパフォーマンス(または比較的長い時間がかかるため、コミットごとに実行されない他のテスト)がある場合にのみ意味があります。 さて、私は別のアプリケーションを思いつきませんでした。

Gitflow
ブランチを適切に整理し、後でそれが耐え難いほど苦痛にならないように、それはすでに長い間考えられていたので、ワークフロー自体に留まらない-私はおおよそのアルゴリズムを書くだけだ:
- すべての機能/バグ修正は別のブランチにある必要があります。 さて、ここではすべてがシンプルです-Stashはgitリポジトリ自体を管理し、ブランチはもちろんサポートされており、ブランチはJiraの課題ウィンドウから直接作成できます。
- 開発者はこのブランチにコードをプッシュします。
- Bambooが新しいブランチを自動的に選択するカスタマイズされたビルドを持っている場合、Stashはビルドが収集されたことを確認します。
- 開発者はPRを作成し、レビュー担当者を任命します。 残念ながら、リストからランダムに手で指名することは不可能です。
- レビュー担当者は、メールで通知を受け取り、変更点(標準の差分または2パネル比較)を確認し、コメントを残すことができます。 実際には、チームのほぼ全員がレビュアーに配置され、編集ボタンがコードに触れた人、またはプロジェクトの影響を受けた部分に最も精通している人が承認ボタンをクリックすることがわかります。
- 開発者はアップグレードを待っており、グリーンビルドが存在する場合、プルリクエストを含めて問題を解決できます。
このプロセスを示すアトラシアンのビデオ:
すべてがどのように緊密に統合されているかを示していますが、このすべて(たとえば、[レビューの開始]ボタン)が機能しませんでした。 バージョンに問題がある可能性があります。
最後に、有用な機能の小さな絞り/可能な質問への回答
- サポートされるプロトコル:HTTP / HTTPSおよびSSH。 最初の場合、パスワード認証、2番目の場合-キーによる。
- 構文の強調表示。
- プルリクエストを作成せずにブランチを比較する機能。
- もちろん、メール通知。 新しいプルリクエスト、作成されたプルリクエストに関する新しいコメントなどについて
- 有料のNotifyrプラグインを使用すると、リポジトリをお気に入りとしてマークし、リポジトリへのすべてのプッシュに関する通知を受け取ることができます。
- これは、ユーザーが管理する権限を持つ個人ユーザーリポジトリをサポートします。
- フォークを作ることができます。 自動同期ブランチもサポートされています。 軟膏で飛ぶ-全員がフォークで作業する開発モデルを使用し、メインリポジトリにプルリクエストを行いたい場合、Bambooの「グリーン」ビルドに依存関係を追加することはできません-フォークの存在を知らないだけです。
- 3.xバージョンでは、コメントが表示されました。 私個人の意見では、オープンソース(非常に大規模で分散したチーム)の場合、少なくともある程度実用的な価値があると考えています。
- ブランチへの直接のコミット(プルリクエストなし)を禁止することはできません(少なくともバージョン2.xには既に3.xがあります)。 実際、マージはgitの機能なので、たとえば、開発中のStashをバイパスする直接マージブランチは、言葉で禁止する必要があります。 もちろん、マージを担当する1人のユーザーのみにブランチへの権限を与えることができますが、これは非常にまれな場合にのみ意味があります。
- Javaでフックを作成し、プラグインとして追加できます(たとえば、前の段落の問題を解決する必要がある場合)。
- Jira / Crowdサーバーをユーザーディレクトリとして使用できます。 各ユーザーは個別にStashユーザーのチェックを外すことができます-これは、Jiraに多くのユーザーがいて、Stashのライセンスがたとえば50ユーザーのみをサポートしている場合に役立ちます。
- メモリ消費の面で十分に貪欲。
- StashとBitbucketの両方が同じ会社の製品であるという事実にもかかわらず、それらのコードベースは異なるため、一方の機能の存在は他方の機能の存在を意味しません。