Facebookの開発プロセスは、これらの方法論から有機的に成長し、特定のスキームに厳密に従うことなく、高速反復の多くの段階を含んでいます。 この柔軟で実用的なアプローチにより、迅速なスケジュールでWebおよびモバイル製品を正常に立ち上げることができました。
長年にわたり、シンプルなマスターおよびリリースブランチ戦略を使用して、Facebookフロントエンドを1日に3回更新しました。 エンジニアは、一連の自動テストに合格したマスターブランチからコードの変更を選択的に選択し、毎日の更新元のリリースブランチに含めました。 通常、この方法で1日あたり500から700の変更が選択されました。 週に一度、新しいリリースブランチを切り離し、その週に選択されなかった変更を収集しました。
このようなシステムは、2007年の数人の開発者から今日の数千人にまで拡大しました。 良いニュースは、プログラマの数が増えると、実行される作業量が増加することです。コードのリリース速度はチームの規模に応じて拡大します。 ただし、毎日および毎週のリリースでは、既存のツールと自動化システムに加えて、リリースを担当する開発者を任命するなど、ある程度の努力が必要でした。 開発者の数が増え続けているため、リリースのためのコードの部分の蓄積が永遠に続くことはないことを理解しました。
2016年までに、フラグメントを手動で選択した2つのブランチのモデルが限界に達したという結論に達しました。 masterブランチには1日あたり1,000件以上の変更が加えられ、毎週のプッシュは10,000件の変更に達しました。 このような大規模なリリースを毎週調整してリリースするための労力は、実行不可能になりました。
2016年4月、 facebook.comをほぼ連続した「マスターからのプッシュ」システムに移行することにしました。 翌年、徐々に従業員の半分を対象に展開し、次に実稼働中のWebトラフィックの0.1％から1％に移行し、その後10％に移行しました。 これらの進歩はそれぞれ、より高いプッシュ頻度で動作し、現実世界からフィードバックを受け取るためのツールとプロセスの能力をテストするのに役立ちました。 主な目標は、新しいシステムがユーザーによるサイトの認識を改善することを確認することでした-まあ、少なくともそれを台無しにしないでください。 2017年4月に3日間のほぼ1年間の計画と開発を経て、100％の運用サーバーを展開して、マスターブランチから直接コードを実行しました。
大規模な継続的なコード配信
真に中断のないソフトウェア配信システムは、すべての変更がすぐに本番に移行することを意味しますが、Facebookの開発速度は数時間ごとに数千の変更をプッシュする独自のシステムを必要としました。 この準連続的なソフトウェア配信システムへの変更は通常、小さくて段階的であり、エンドユーザーに実際に見えるものはほとんどありません。 各リリースは、数時間で複数の段階で本番サーバーの100％にロールアウトされるため、問題が見つかった場合はプッシュを停止できます。
一連の内部自動テストに合格し、masterブランチに落ちた変更は、Facebook従業員向けに展開されます。 この段階で、リグレッションを行った場合、プッシュのブロックに関するアラートが提供され、緊急停止ボタンはリリースのさらなる配布をすぐに停止します。 すべてが正常な場合、2％の実稼働サーバーの変更を展開します。特に極端な場合はフィードバックを収集し、警告を追跡します。特に極端な場合は、従業員でテストすると気付かないことがあります。 最終的に、100％生産のための変更を展開し、Flytrapツールはユーザーレポートを収集し、異常について通知します。
Gatekeeperシステムでは、多くの変更が最初に行われ、新機能に関係なくWebおよびモバイルバージョンのリリースがロールアウトされます。 これにより、特定の更新が問題を引き起こすリスクを軽減できます。 問題が見つかった場合は、前のバージョンに戻ったり次のバージョンで修正したりするのではなく、単にゲートキーパーをオフにします。
準連続リリースサイクルにはいくつかの利点があります。
パッチは必要ありません 。 1日に3回の腕立て伏せを行うシステムでは、スケジュールに合わない重大な変更が緊急に必要な場合、パッチを適用する必要がありました。 これらの予定外のプッシュは、開発者側である程度の努力を必要とし、次回の予定されたプッシュと競合する可能性があるため、有害です。 新しいシステムでは、ほとんどの場合、パッチを必要とする変更はmasterブランチに対して行われ、次のリリースでロールされます。
グローバル開発チームへの最高のサポート 。 私たちは、世界のさまざまな地域の開発オフィスの作業スケジュールに毎日3回のプッシュを適応させようとしましたが、そのような状況でも、1週間に1回のリリースでは特定の日時にすべての開発者の注意が必要でした。 新しい準連続システムにより、任意のタイムゾーンのすべての開発者が都合の良いときにコードを記述して配信できるようになります。
スケーリングに必要な新しいツール、自動化、プロセスを作成するためのインセンティブ 。 このようなプロジェクトを取り上げると、多くの開発チームとシステムの圧力テストのようなものになります。 その結果、プッシュツール、変更レビューツール、テストインフラストラクチャ、容量管理システム、トラフィックルーティングシステムを改善し、他の多くの分野で改善を行いました。 これらすべてのシステムの開発者は、クイックリリースプロジェクトの成功を望んでいました。 その結果、行われた改善は、会社が将来の成長に備えるのに役立ちます。
ユーザーの利便性 。 新しいコードの動作を学習するのに数日と数週間かかる場合、開発者はすでに別の仕事に移っているかもしれません。 継続的なソフトウェアの供給により、エンジニアは、行われた変更に関するフィードバックを得るために1週間以上待つ必要がありません。 彼らはすぐに機能しない情報を受け取り、準備ができたらすぐに小さな変更をロールアウトし、次の大きなリリースを期待しません。 インフラストラクチャの観点から見ると、この新しいシステムは、人々に影響を与える可能性のあるまれなイベントに対応する場合にはるかに便利です。 最終的に、エンジニアはサイトのユーザーにより近くなり、開発の品質と製品の信頼性の両方が向上しました。
モバイルプラットフォーム向けの継続的デリバリーアプリケーション
Web上の準連続システムへの移行が可能になったのは、技術スタック全体を制御し、必要なツールを作成または改善できるためです。 モバイルプラットフォームでの開発と実装のための既存のツールの多くは、継続的なソフトウェアリリースの高速な反復をサポートしていないため、モバイルプラットフォームへの配信はより困難な作業です。
Facebookはこの分野の状況を改善しようとし、急速なモバイル開発に特化した多くの無料ツールをリリースしました。 その中には、 Nuclide 、 Buck 、 Phabricator 、iOS用のさまざまなライブラリ、 React Native、およびInferがあります。 これらのアセンブリツールとテストツールを組み合わせることで、モバイルプラットフォームで迅速に配信できる高品質のコードを生成できます。
継続的インテグレーションスタックは、ビルド、静的分析、テストの3つのレベルで構成されています。
開発ブランチからモバイルマスターブランチにコードが届くとすぐに、関連するすべての製品のコードが最初に収集されます。 モバイルプラットフォームでは、これは各コミットのFacebook、Messenger、Pages Manager、Instagramおよびその他のアプリケーションのビルドに適用されます。 また、各アプリケーションのいくつかのバリアントを収集して、このプログラムがサポートするすべてのマイクロプロセッサアーキテクチャとシミュレータがカバーされるようにします。
ビルドの到着中に、リンターとInferコードの静的分析ツールを起動します。 これは、nullポインター例外、リソースとメモリリーク、未使用の変数、危険なシステムコールの特定、およびFacebookプログラミングルールとの矛盾の特定に役立ちます。
3番目の並列システムであるモバイル自動テストには、Robolectric、XCTest、Junit、WebDriverなどのツールを使用して実施される数千の単体テスト、統合テスト、エンドツーエンドテストが含まれています。
ビルドおよびテスト用のこのツールセットは、各コミットで起動されるだけでなく、コードの各変更のライフサイクル中に何度も起動されます。 Androidでのみ、1日あたり50,000〜60,000ビルドを収集します。
モバイルスタックでソフトウェアを継続的に配信する従来の方法を使用して、4週間ごとのリリースから2週間に切り替えてから、毎週のサイクルに切り替えました。 現在、モバイルプラットフォームでは、以前はWebで使用されていた変更の手動選択の同じモデルを使用しています。 運用環境への変更は1週間に1回だけ展開しますが、エンジニアがユーザーから事前にフィードバックを受け取ることができるように、実際の条件でコードを事前にテストすることも重要です。 ベータテスターのリリース候補を毎日リリースしていますが、そのうち約100万人がAndroidのテスターです 。
リリースリリースの頻度を増やしましたが、モバイルプラットフォームの開発者の数は15倍増加し、開発速度も大幅に向上しました。 それにもかかわらず、 2012年から2016年のデータは 、コードの行数とプッシュ数の両方で、エンジニアの生産性がAndroidとiOSで変わらないことを示しています。 また、リリースの数に関係なく、モバイルアプリケーションの重大な問題の数はそれほど変化していません。つまり、スケーリングの結果としてコードの品質が低下していません。
利用可能なツールと方法論のそのような改善の中でリリース設計の分野で働くことは非常に楽しいです。 私の意見では、世界でこの規模の最先端のWebおよびモバイルアプリケーション展開システムを作成するために協力してくれたFacebook開発チームを非常に誇りに思っています。 これは、インフラストラクチャ開発部門のリーダーであった強力なリリース設計チームなしでは不可能でした。 このFacebookグループは、開発者とユーザーのリリースプロセスを改善するイニシアチブを引き続き推進し、経験、ツール、およびベストプラクティスを共有し続けます。