Flowのごくごく基本的な部分についておさらいしてみました。基本ということで、CIやデプロイについては触れず、レビュー後にすぐマージする形でお話をしました。Requestブランチを本番環境にデプロイするのが基本的な流れになります。本番環境以外にも複数のテスト用環境が用意されており、場合によって複数のテスト環境で動作を確認してから本番環境へデプロイする場合も多くあります。デプロイフローは自動化されており、ブランチを本番環境にデプロイする前に、自動的にCIが実行され、コードが正しく動作するかがチェックされます。デプロイ後に本番環境にて問題なく動作することを確認後、masterブランチにマージします。逆に動作に不審な点があった場合にはマージせず、代わりにmasterを本番環境にデプロイし直すことで巻き戻しを行います。この流れについて詳細はぜひこちらの記事をご覧ください。GitHub.com弊社が実施しているフローは、弊社に最適化したフローです。ほとんどの作業が自動化され1日に何百回とデプロイできるフローですから、自信を持っておすすめできるフローではあります。言え、このフローを実現するためには整備しなければならないことが大量にあり、いきなり実現できるものではありません。弊社もここに至るまでに数年を費やしていますし、今も継続的に改善している最中です。ソフトウェア開発には様々な形態があり、目指すゴールやサイクルも違います。最適なワークフローもまた、組織によって、扱っているソフトウェアの種類によって、様々です。GitHubには、様々なワークフローの構築を助けるような、種々の便利な機能が用意されています。今回はそのうちのいくつかを紹介したいと思います。Branches)ワークフローをどう構築するか考える際に、多くの組織でどうするべきか議論になるのがブランチの扱いです。Requestを介さずにmasterブランチに直接Pushしてしまうと、レビューもされずテストもされないコードがmasterに入ってしまうことになります。Flowの大原則である"masterは常に本番環境にデプロイ可能な状態を保つ"というルールにも反します。前述の通り、本番環境の巻き戻しをする際にmasterをデプロイし直すことで担保することから考えても、絶対に侵してはならないルールの1つです。Branches"という機能です。Enterpriseにはバージョン2.4から追加されています。この機能は、様々な機能を内包しているのですが、シンプルに言うとまず下記の2つの好ましくない動作から当該ブランチを保護できます。Branchesによってこれを完全に防止できます。この機能によって、masterブランチのような重要なブランチを削除されることも防げます。リポジトリ毎に設定できるようになっており、次の図のようにSettingタブからBranchesメニューをクリックするとアクセスできます。Branchesの設定ができます。デフォルトブランチは特に変える必要なければmasterのままにしておきましょう。branch..."と書かれたプルダウンリストから選びます。ここではmasterを選びましょう。changes"を押して保存しましょう。Branchesの基本的な機能ですが、実は他にも付随機能があります。merging"というチェックボックスがあるのに気づいたでしょうか。このチェックボックスをOnにすると、マージの前にレビューを通過することが必須条件になります。ここでいう"レビューを通過する"というのは、今年秋に発表した新しいコードレビュー機能のことを指します。Enterpriseにおいては最新のバージョン2.8よりお使いいただけます。changes"の3種類のステータスによって提案者に知らせることができます。Branchesにおいて、レビューを必須にする設定を行うと、レビュワーのうちの誰かがステータスを"Approve"にしない限りマージできなくなります。※12月8日、新たにレビュワーを指定できる機能がGitHub.comに追加されました。この機能はあくまでレビュワーを指定できるのみであり、必ずしも指定したレビュワーがApproveしなくとも、誰かがApproveすればマージ可能になる点は従来通りですのでご注意ください。Enterpriseにはまだ搭載されていませんのでその点もご了承ください。Requestを使わず、masterブランチに直接Pushしようとしても同様に拒否されます。Requestを使うことと、必ずレビューをすることを強制することができます。Requestを使わずに勝手にmasterにコードをPushされて困る」といった状況があるのであれば、この機能を使うことで簡単に防止できます。administrators"にチェックを入れると、当該リポジトリに対してAdmin権限を持っているユーザーに対しても、レビューなしのPushを禁ずることができます。Statusの機能です。merging"をOnにすることで設定可能です。すると次のようにチェックボックス以下が展開されます。administrators"は先程と同様にAdminであってもこのチェックを必須とするかどうかの設定です。date(最新状態)になっていることを必須にするかどうかです。Requestがmasterにマージされたことで、masterブランチが当初より先に進んでしまったようなケースをどうするかの設定です。通常は、進んでしまったmasterの内容を当該ブランチにマージして、再度テストとレビューを実施します。ないと現在テスト/レビュー中の当該ブランチが間違いなく最新であることを担保できないためです。前述の通り、この設定はデフォルトではOnになっており、Onの場合はマージの際に次のような画面が出てきます。request"ボタンが押せない状態になっているのが分かるでしょうか。branch"というボタンを押して、Baseブランチの内容を当該ブランチにマージしてからでないと、masterにマージできません(なお、状況によってはコンフリクトが起きるためにこのボタンが使えない場合もあります。その際にはローカルPC上で手動でマージを行う必要があります)。merging"をOffにすると、このチェックが必須でなくなります。通常はおすすめしませんが、ワークフローによっては別のフェーズで品質を担保するため、ここではチェックを掛けなくてよいというケースも存在します。dateしていると何回も長時間のテストを実行する羽目になる、などのケースがあります)。checkになります。先程の画面をもう一度見てみましょう。checks..."と表示されているかと思います。APIを使って、当該ブランチのコミットに対してStatusのアップデートを最低一回行う必要があります。しないとこの画面上にリストアップされてきません。次の画面が、一度実行して、リストアップされた状態です。ここでは4つリストアップされています。左端にあるチェックボックスをチェックすることで、各々のチェックを必須のものとするか、任意にするかを決められます。必須にしたものは、必ずStatusがSuccessにならないとマージできなくなります。Approval"が必須になっています。"CI-by-Jenkins"は、その名前から分かる通り、ここではJenkinsによる自動テストを表してます。APIによって自由に設定が可能です。checkで使えるCIサービスとしては他にも、TravisCI、CircleCIなど多数あります。Pluginが設定も簡単でおすすめです。Jenkins2系のセットアップ時にデフォルトでインストールを指定できます。Enterpriseともよく動作します。pluginを使うのが一般的です。Directoryから連携ボタンを押すことで簡単に連携を実現することも可能です。Enterpriseの場合は少々手作業が発生しますが、近い感覚で設定できます。APIを使えば、独自のチェックを追加することも可能です。詳細はぜひこちらの実装ガイドをご覧ください。Requestを使わず、チェックを通過していないコードをmasterブランチに直接Pushしようとしても同様に拒否されます。マージできる人/チームを制限する最後がこの機能です。当該ブランチへのマージを特定の人およびチームに制限するという機能です。この機能は今年の3月頃GitHub.comに追加されました。Enterpriseにおいてはバージョン2.6より利用可能になっています。この機能は個人リポジトリには設定できず、Organization配下のリポジトリのみ設定可能な機能になります。Organization配下のリポジトリの場合、次の画面のようにチェックボックスが従来に加えて1つ追加されています。branch"にチェックを入れると次のように検索ダイアログが開きますので、権限を付与したい人を直接入力するか、付与したいチームを入力してください。この設定によって、マージの最終承認者を厳格に決めたい、と言ったニーズに応えることができます。これも他と同様に、マージだけでなく実質的には当該ブランチのPushそのものを保護していますので、当該メンバーに含まれないユーザーはmasterへのPush自体できなくなります。Branchesというブランチを保護する機能を見てきました。まとめると、次のようなことができるようになります。Flowのような軽量なワークフローを実践することが可能になります。安全の担保度合いについては、組織やプロジェクトの性格に応じて、ゆるくすることも固く引き締めることも可能になっています。Flowは、うまく運用すれば社内の開発者文化をよりオープンにし、自由闊達なコラボレーションを可能にします。インナーソースの醸成に役に立ちます。一方で自由すぎて不安であるとの声があったのも事実で、今回紹介した機能をうまく使えれば、より安全を担保したい場合にも対応できます。Flowをベースに、より皆さんのプロジェクトにあったワークフローを模索してみてください。Request単位でのRevertやビジュアルなBlame機能などについて触れたいと思います。ITコンサルタントとしてキャリアをスタート。その後コンサルタントからプログラマーに転身し、パッケージソフトウェア開発、Webサービス開発を経て、2015年現在GitHubにてソリューションエンジニアとして働いている。ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。VeloCloudが選ばれる理由SD-WANとはなにか。Linuxエンジニア育成への思いF5とNGINXの組み合わせで、サービス公開をよりセキュアに。ITがお届けするポッドキャストです。