CI導入に関するGitHubの見解

継続的インテグレーションとは

継続的インテグレーションは、開発者が定期的にコードの変更をセントラルリポジトリにマージし、結合する開発手法です。これらの変更は、初期段階でエラーを検知できるよう、自動化されたビルドを通してテストされます。本番環境で生じる不具合の数を減らし、全体的な品質と効率性を高めながらフィードバックサイクルを短縮するには、早期にバグを自動検出することが重要です。CIプロセスは、Gitのようなバージョン管理システムと組み合わせて使うと特に効果的です。定期的にコードをマージする必要があるCIの利点が加わることで、Gitではバージョン管理を通してコードの整合性と品質を保持できます。

継続的インテグレーションの導入

新しいツールが開発され、セットアップの簡素化が進んでいるとはいえ、多くの組織にとってCIの導入はまだまだ大変です。CIの導入を成功させるには、ツールだけではなく、組織の技術面と文化面の両方で、柔軟性とコラボレーションをサポートする必要があります。組織構造と運用構造が適切であれば、エンジニアは知識を共有し、チームの枠を超えて貢献し合い、最高の仕事をすることができます。

以下に、効果的なCIプラクティスを実践中のチームから集めた、3つの重要な洞察を紹介します。チームにおけるワークフローの進化および調整のために役立ててください。

CIの導入を成功させるには、「適切な技術力」と「成功させようという協力的な文化」の両方が必要です。
「ツール使用」と「意識」の両方を、チームと同じ速さで進化させる必要があります。
他のチームでうまくいったことが自分のチームに適しているとは限りません。柔軟な姿勢で、チームにとって効果的な選択をすることが重要です。

組織が製品の複雑化、チームの成長、開発プラクティスの進化などに直面した際に、そうした変化にうまく対応できていないケースがよく見受けられます。そのような場合は、柔軟な企業文化を浸透させることで、チームや製品の変化に合わせて変化できるようになります。組織が共同作業を重要視するカルチャーを浸透させることで、組織自身が進化することが可能になり、環境の変化は破壊ではなくビジネスビジネスチャンスとなります。

CIに最適なGitHub

CIと自動テストを導入することででバグを減らし、ビルドの品質を保つことが可能になります。それにより、開発者は安心してコードを一日に何度もマージできます。GitHubを使えば、チームはバージョン管理を確実に行うことができるだけでなく、CI導入を成功させるための基盤を構築することができます。

GitHub Flow で効率よくタスク管理

GitHub Flowは、チームが品質とコード変更などの意図の両方を簡単に確認できる、軽量なブランチベースのワークフローです。

GitHub FlowではコードレビューがすべてPull Requestで実行されるので、ステータスチェックやその他の自動チェックを直感的に行うことができます。「リリース」プロセスを対象とするGit Flowに対し、GitHub Flowは一日を通して継続的にコードをデプロイする開発者に適しています。

GitHub Flow:

masterブランチからブランチを作成し、わかりやすい名前を付けます
コード変更を行います
フィードバック、レビュー、またはマージを行う準備が整ったら、Pull Requestをオープンします。マージする前にPull Requestがレビューされるようにポリシー設定することも可能です
レビューが完了したら、Pull Requestをマージできます
マージする際には、masterブランチが常にデプロイ可能である必要があります

文化と意識

選択するツールと同様に、企業文化は、エンジニアリングチームの開発手法や構築するソフトウェアの品質に思いがけない影響を及ぼします。

柔軟で透明性の高い企業文化を形成することは容易ではありません。一部の企業はインナーソース(オープンソースソフトウェア開発手法にならった開発手法)を導入して成功を収めています。

「自動化されたビルド」「テスト」「バージョン管理」は、製品に変革をもたらすことのできる強力なツールです。開発者がCIツールを最大限に活用するには、「コードに対するフィードバック」「アイデアの共有」「変更を加えて品質を高める」などを促進するプロセスが必要です。こうしたプロセスによる変更を定期的に加えていくことによって、CI導入を成功させることができます。

自由なインテグレーション

組織はそれぞれ異なりますが、どのチームにおいても、適切なツールセットを選択できる柔軟性が必要です。GitHubは、何百ものサードパーティー製ツールと統合できます。その中でも人気の高いものやインテグレーションに定評のあるものは、GitHub MarketplaceやWorks with GitHub ディレクトリから入手可能です。

また、GitHub.comのオープンソースインテグレーションだけでなく、サードパーティーが提供するオプションも利用できます。チームに適したツールが見つからない場合は、 APIやwebhooks を使って、独自のツールを構築できます。

テクノロジーと機能

権限レベルで保護されたブランチ

チームメンバー全員がmasterブランチでコードをコミットおよび変更できる状況ではミスが生じる可能性がありますが、GitHubでは、混乱を制御し、チームがコードの一貫性と品質を維持することのできる手段が提供されています。

保護されたブランチでは、指定したブランチへの書き込み権限を持つ個人またはチームを定義し、過失による削除やフォースプッシュを避けることができます。また、ステータスチェック必須を設定し、マージの前にコードレビューを実行することも可能です。

ブランチを保護する方法について学ぶ

コード所有者

コード所有者は、作業中のブランチのセキュリティをさらに高めます。コード所有者がリポジトリに対して行ったPull Requestはすべて、コード所有者によるレビューが自動的に必須となります。その方法は、CODEOWNERSファイルを追加してコード所有者を定義し、リポジトリの設定画面のブランチタブで、 Require review from code owners（コード所有者によるレビューを必須）」を設定するだけです。

Pull Requestレビューは非常に有益ですが、組織はさらにヒューマンエラーをなくす必要があります。

コード所有者を割り当てることで、バグ修正にかかる全体的な時間が次第に短縮されます。また、開発者とチームとの距離が縮まることによって、コードを最良のものにするための議論が活発化していきます。

コード所有者の設定について学ぶ

DevOpsのためのChatOps：Hubot

ChatOpsでは、開発者が既に使用しているコミュニケーションツールを利用して作業の一部を自動化できます。開発者はフィードバックループを減らすことができ、問題が生じた際にはチャットプラットフォームから通知を直接受け取ることができます。また、SlackなどのチャットアプリケーションでChatOpsコマンドを使えば、CIジョブステータスや他の役立つ情報を即座に得ることも可能です。

以下に、GitHubでよく使われている運用コマンドをいくつか紹介します。

hubot ci setup <name>
hubot ci build <repo>/<branch>
hubot deploy ci to production
hubot ci node reboot <node>
hubot ci node start <node>
hubot ci node stop <node>

例：

開発者が作業に適したツールを透過的に使用できれば、より優れたソフトウェアを開発することができます。開発チームの成功は、柔軟性とスピードを支える文化的かつ技術的な基盤があるかどうかで決まります。適切なチェックを行っているチームは、慎重かつアジャイルに開発することができるため、開発者は問題に対処するための新しい方法を自由に試し、調査することができます。GitHubとCIは、チームがこの基盤を構築するのに役立ちます。