現在、ほとんどのソフトウェア製品はチームで開発されています。 チーム開発が成功するための条件は、簡単な図の形で表現できます。

コードを作成したら、次のことを確認する必要があります。

1. うまくいきます。
2. 同僚が書いたコードも含めて、何も壊れることはありません。

両方の条件が満たされていれば、成功への道を進んでいます。 これらの条件を簡単に確認し、収益性の高い道から外れないようにするために、私たちは継続的インテグレーションを思いつきました。

CI は、コードをできるだけ頻繁に製品コード全体に統合するワークフローです。 また、単に統合するだけでなく、すべてが機能していることを常にチェックします。 頻繁に大量のチェックを行う必要があるため、自動化を検討する価値があります。 すべてを手動で確認することもできますが、そうすべきではありません。その理由は次のとおりです。

• 親愛なる皆さん。 プログラマーの XNUMX 時間の作業は、サーバーの XNUMX 時間の作業よりも高価です。
• 人は間違いを犯す。 したがって、テストが間違ったブランチで実行されたり、テスター向けに間違ったコミットがコンパイルされたりする状況が発生する可能性があります。
• 人々は怠け者です。 時々、タスクを終えたときに次のような考えが浮かびます。 XNUMX 行書きましたが、すべてうまくいきました。 皆さんの中にも、時々そんな思いを抱く人もいると思います。 しかし、常にチェックする必要があります。

Avito モバイル開発チームで継続的インテグレーションがどのように実装および開発されたか、0 日あたり 450 から 200 のビルドがどのように行われたか、そしてビルド マシンは XNUMX 日 XNUMX 時間組み立てられたと Nikolai Nesterov 氏は述べています (ネステロフ) は、CI/CD Android アプリケーションのすべての進化的変更に参加しています。

この話は Android コマンドの例に基づいていますが、ほとんどのアプローチは iOS にも適用できます。

昔々、Avito Android チームで XNUMX 人が働いていました。 定義上、彼は継続的インテグレーションから何も必要としませんでした。統合する相手がいなかったのです。

しかし、アプリケーションは成長し、新しいタスクがどんどん登場し、それに応じてチームも成長しました。 ある時点で、コード統合プロセスをより正式に確立する時期が来ます。 Git flow を使用することにしました。

Git フローの概念はよく知られています。プロジェクトには XNUMX つの共通の開発ブランチがあり、開発者は新機能ごとに別のブランチを切り取り、そこにコミットしてプッシュし、コードを開発ブランチにマージする場合は、プルリクエスト。 知識を共有し、アプローチについて話し合うために、コード レビューを導入しました。つまり、同僚がお互いのコードをチェックして確認する必要があります。

小切手

コードを目で見るのは素晴らしいことですが、それだけではありません。 したがって、自動チェックが導入されています。

• まず最初に確認します ARKアセンブリ.
• たくさん Junit テスト.
• コードカバレッジを考慮します、テストを実行しているためです。

これらのチェックをどのように実行するかを理解するために、Avito の開発プロセスを見てみましょう。

これは次のように図式的に表すことができます。

• 開発者はラップトップでコードを書きます。 ここで統合チェックを実行できます。コミットフックを使用するか、バックグラウンドでチェックを実行するだけです。
• 開発者はコードをプッシュした後、プル リクエストを開きます。 そのコードを開発ブランチに含めるためには、コードレビューを通過し、必要な数の確認を収集する必要があります。 ここでチェックとビルドを有効にできます。すべてのビルドが成功するまで、プル リクエストはマージできません。
• プル リクエストがマージされ、コードが開発に組み込まれた後は、すべてのサーバーが空いている夜間など、都合のよい時間を選択して、好きなだけチェックを実行できます。

ラップトップでスキャンを実行するのが好きな人は誰もいませんでした。 開発者は、機能が完成したら、すぐにプッシュしてプル リクエストをオープンしたいと考えます。 この時点で長いチェックが開始されると、これはあまり快適ではないだけでなく、開発の速度も低下します。ラップトップが何かをチェックしている間、通常どおりに作業することは不可能です。

夜間にチェックを実行するのがとても気に入りました。時間もサーバーもたくさんあるので、歩き回ることができるからです。 しかし、残念ながら、機能コードが開発に入ると、開発者は CI で見つかったエラーを修正する意欲が大幅に低下します。 朝のレポートで見つかったすべてのエラーを見て、いつかそれらを修正するだろうと定期的に考えていました。Jira には今すぐ始めたい素晴らしい新しいタスクがあるからです。

チェックがプル リクエストをブロックする場合は、十分なモチベーションが得られます。ビルドが緑色になるまでコードは開発に入らないため、タスクは完了しません。

その結果、私たちは次の戦略を選択しました。夜間に可能な限り最大限のチェック セットを実行し、その中で最も重要なもの、そして最も重要なことに、プル リクエストで最も高速なものを起動します。 しかし、そこで止まるわけではありません。並行して、チェックの速度を最適化して、チェックを夜間モードからプル リクエスト チェックに転送します。

その時点では、すべてのビルドが非常に早く完了したため、プル リクエストのブロッカーとして ARK ビルド、Junit テスト、コード カバレッジの計算を含めるだけでした。 私たちはコード カバレッジをオンにし、検討しましたが、コード カバレッジは必要ないと考えたため、コード カバレッジを放棄しました。

基本的な CI を完全にセットアップするのに XNUMX 日かかりました (以下、推定時間は概算であり、スケールに必要です)。

その後、私たちはさらに考え始めました。正しくチェックしているだろうか？ プル リクエストでビルドを正しく実行していますか?

プル リクエストが開かれたブランチの最後のコミットでビルドを開始しました。 ただし、このコミットのテストでは、開発者が作成したコードが機能することのみを確認できます。 しかし、彼らは彼が何も壊さなかったことを証明しません。 実際、機能が開発ブランチにマージされた後、開発ブランチの状態を確認する必要があります。

これを行うために、単純な bash スクリプトを作成しました。 プリマージ.sh:

#!/usr/bin/env bash

set -e

git fetch origin develop

git merge origin/develop

ここでは、開発からのすべての最新の変更が単純にプルアップされ、現在のブランチにマージされます。 すべてのビルドの最初のステップとして premerge.sh スクリプトを追加し、必要なものを正確にチェックし始めました。 統合.

問題の場所を特定し、解決策を見つけて、このスクリプトを作成するのに XNUMX 日かかりました。

アプリケーションが開発され、ますます多くのタスクが発生し、チームが成長し、premerge.sh が時々私たちを失望させ始めました。 矛盾する変更が開発に入り、ビルドが中断されました。

これがどのように起こるかの例:

XNUMX 人の開発者が同時に機能 A と B の作業を開始します。機能 A の開発者は、プロジェクト内で未使用の機能を発見しました。 answer() そして、優秀なボーイスカウトのように、それを取り除きます。 同時に、機能 B の開発者は、ブランチ内のこの関数への新しい呼び出しを追加します。

開発者は作業を完了すると同時にプルリクエストをオープンします。 ビルドが起動され、premerge.sh が最新の開発状態に関する両方のプル リクエストをチェックします。すべてのチェックは緑色です。 その後、フィーチャー A のプル リクエストがマージされ、フィーチャー B のプル リクエストがマージされます...ドーン！ 開発コードに存在しない関数の呼び出しが含まれているため、開発が中断されます。

発展しないときは、 地元の災害。 チーム全体が何かを収集してテストに提出することはできません。

たまたま、私は分析、ネットワーク、データベースなどのインフラストラクチャのタスクに取り組むことが最も多かったです。 つまり、他の開発者が使用する関数やクラスを作成したのは私です。 このため、私も同じような状況に頻繁に遭遇しました。 この写真もしばらく飾ってありました。

これは私たちには合わなかったため、これを防ぐ方法を検討し始めました。

開発を中断しない方法

最初のオプション： 開発を更新するときにすべてのプルリクエストを再構築します。 この例では、機能 A のプル リクエストが最初に開発に含まれる場合、機能 B のプル リクエストが再構築されるため、コンパイル エラーによりチェックが失敗します。

これにどれくらいの時間がかかるかを理解するために、2 つの PR がある例を考えてみましょう。 1 つの PR を開きます。3 つのビルドと XNUMX つのチェックの実行です。 最初の PR を開発にマージした後、XNUMX 番目の PR を再構築する必要があります。 合計で、XNUMX つの PR には XNUMX 回のチェック実行が必要です (XNUMX + XNUMX = XNUMX)。

原則的には大丈夫です。 しかし、統計を見てみると、私たちのチームの典型的な状況は 10 個のオープン PR であり、チェックの数は進行の合計である 10 + 9 +... + 1 = 55 です。つまり、10 個を受け入れることになります。 PR の場合、55 回再構築する必要があります。 そして、これは理想的な状況であり、最初にすべてのチェックに合格し、これらの数十件が処理されている間、誰も追加のプル リクエストをオープンしないときです。

自分が開発者で、最初に「マージ」ボタンをクリックする必要があると想像してください。隣人がこれを行うと、すべてのビルドが再度完了するまで待たなければなりません...いいえ、それは機能しません。 、開発が大幅に遅くなります。

XNUMX 番目に考えられる方法: コードレビュー後にプルリクエストを収集します。 つまり、プル リクエストを開き、同僚から必要な数の承認を集め、必要なものを修正して、ビルドを開始します。 成功すると、プル リクエストは開発にマージされます。 この場合、追加の再起動はありませんが、フィードバックは大幅に遅くなります。 開発者として、プル リクエストを開いたら、それが機能するかどうかをすぐに確認したいと思います。 たとえば、テストが失敗した場合は、すぐに修正する必要があります。 ビルドが遅れると、フィードバックが遅くなり、開発全体が遅くなります。 これも私たちには合わなかった。

その結果、残ったのは XNUMX 番目の選択肢だけでした - サイクリング。 すべてのコード、すべてのソースは Bitbucket サーバー上のリポジトリに保存されます。 したがって、Bitbucket 用のプラグインを開発する必要がありました。

このプラグインは、プル リクエストのマージ メカニズムをオーバーライドします。 始まりは標準です。PR が開き、すべてのアセンブリが起動され、コード レビューが完了します。 ただし、コード レビューが完了し、開発者が「マージ」をクリックすると、プラグインはどの開発状態に対してチェックが実行されたかをチェックします。 ビルド後に開発が更新された場合、プラグインはそのようなプル リクエストをメイン ブランチにマージすることを許可しません。 比較的最近の開発のビルドを再開するだけです。

競合する変更を含むこの例では、そのようなビルドはコンパイル エラーにより失敗します。 したがって、機能 B の開発者はコードを修正し、チェックを再開する必要があります。その後、プラグインが自動的にプル リクエストを適用します。

このプラグインを実装する前は、プル リクエストあたり平均 2,7 回のレビューを実行していました。 プラグインでは 3,6 が起動されました。 これは私たちにぴったりでした。

このプラグインには欠点があることに注意してください。それは、ビルドを XNUMX 回しか再起動しないことです。 つまり、競合する変更が開発に入る可能性がある小さなウィンドウがまだ存在します。 しかし、その可能性は低いため、開始回数と失敗の可能性の間でトレードオフを設定しました。 XNUMX年間で点火したのはXNUMX回だけだったので、おそらく無駄では​​なかったでしょう。

Bitbucket プラグインの最初のバージョンを作成するのに XNUMX 週間かかりました。

新しい小切手

その間、私たちのチームは成長を続けました。 新しいチェックが追加されました。

私たちは、「防げるのなら、なぜ間違いを犯すのか？」と考えました。 そしてそれが彼らが実装した理由です 静的コード分析。 まずは Android SDK に含まれる lint から始めました。 しかし、当時彼は Kotlin コードの操作方法をまったく知りませんでした。また、アプリケーションの 75% はすでに Kotlin で書かれていました。 したがって、組み込みのものはlintに追加されました Android Studio のチェック。

これを行うには、多くの倒錯を行う必要がありました。Android Studio を取得し、Docker にパッケージ化し、仮想モニターを使用して CI 上で実行することで、Android Studio が実際のラップトップ上で実行されていると思わせるようにしました。 しかし、それはうまくいきました。

私たちがたくさんのことを書き始めたのもこの時期でした 計測テスト そして実装されました スクリーンショットのテスト。 これは、別の小さなビューに対して参照スクリーンショットが生成される場合であり、テストはビューからスクリーンショットを取得し、それをピクセルごとに標準と直接比較することで構成されます。 矛盾がある場合は、どこかでレイアウトが間違っているか、スタイルに問題があることを意味します。

ただし、インストルメンテーション テストとスクリーンショット テストは、デバイス (エミュレータまたは実際のデバイス) 上で実行する必要があります。 テストが多数あり、頻繁に実行されることを考慮すると、ファーム全体が必要になります。 独自のファームを立ち上げるのは労力がかかりすぎるため、既製のオプションである Firebase Test Lab を見つけました。

Firebase テスト ラボ

これが選ばれたのは、Firebase が Google 製品であるため、つまり信頼性が高く、停止する可能性が低いという意味です。 価格は手頃です。実際のデバイスの操作は 5 時間あたり 1 ドル、エミュレータの操作は XNUMX 時間あたり XNUMX ドルです。

Firebase Test Lab を CI に実装するのに約 XNUMX 週間かかりました。

しかし、チームは成長を続け、残念ながら Firebase は私たちを失望させ始めました。 当時、彼には SLA がありませんでした。 Firebase では、テストに必要な数のデバイスが空くまで待たされ、希望どおりにすぐにテストの実行が開始されないことがありました。 列に並んで待つのは最大XNUMX分かかり、非常に長い時間でした。 すべての PR でインストルメンテーション テストが実行され、遅延により開発が大幅に遅れ、その後、月々の請求額が合計額で請求されました。 一般的に、チームが十分に成長したため、Firebase を放棄して社内で作業することが決定されました。

ドッカー + Python + バッシュ

私たちは Docker を導入し、そこにエミュレータを詰め込み、Python で簡単なプログラムを書きました。これは、適切なタイミングで、必要なバージョンの必要な数のエミュレータを起動し、必要に応じて停止します。 そしてもちろん、いくつかの bash スクリプトも必要です。これらがなければどうなるでしょうか?

独自のテスト環境を作成するのに XNUMX 週間かかりました。

その結果、すべてのプル リクエストに対して、広範なチェックのマージ ブロック リストが存在しました。

• ARK アセンブリ。
• Junit テスト。
• 糸くず;
• Android Studio のチェック。
• 計装テスト。
• スクリーンショットのテスト。

これにより、起こり得る多くの故障が防止されました。 技術的にはすべてうまくいきましたが、開発者は結果を待つ時間が長すぎると不満を言いました。

長すぎるってどれくらいですか？ Bitbucket と TeamCity からのデータを分析システムにアップロードしたところ、次のことがわかりました。 平均待ち時間45分。 つまり、開発者はプル リクエストを開くと、ビルド結果が得られるまで平均 45 分待機します。 私の意見では、これは大変なことであり、そのように働くことはできません。

もちろん、すべてのビルドを高速化することにしました。

スピードアップしましょう

ビルドがキューで待機していることが多いため、最初に行うことは次のとおりです。 さらにハードウェアを購入しました — 大規模な開発が最も簡単です。 ビルドのキューは停止しましたが、一部のチェック自体に非常に長い時間がかかるため、待ち時間はわずかに減少しました。

時間がかかりすぎるチェックの削除

当社の継続的インテグレーションは、この種のエラーや問題を検出できます。

• 行かない。 変更の競合により何かがビルドされない場合、CI はコンパイル エラーを検出することがあります。 すでに述べたように、そうなると誰も何も組み立てることができなくなり、開発が停止し、誰もが不安になります。
• 動作のバグ。 たとえば、アプリケーションは構築されたが、ボタンを押すとクラッシュするか、ボタンがまったく押されない場合です。 このようなバグがユーザーに届く可能性があるため、これは問題です。
• レイアウトのバグ。 たとえば、ボタンをクリックしたが、左に 10 ピクセル移動したとします。
• 技術的負債の増加.

このリストを見た後、最初の XNUMX つの点だけが重要であることがわかりました。 そういった問題をまずは捉えていきたいと思っています。 レイアウトのバグはデザインレビューの段階で発見され、その後簡単に修正できます。 技術的負債に対処するには別のプロセスと計画が必要なため、プル リクエストではテストしないことにしました。

この分類に基づいて、チェックのリスト全体を見直しました。 糸くずに取り消し線を付けた そしてプロジェクトの立ち上げを一晩延期しました。それは、プロジェクトにどれだけの問題があったのかについてのレポートを作成するためでした。 私たちは技術的負債については別々に取り組むことに同意しました。 Android Studio のチェックは完全に放棄されました。 Docker で Android Studio を使用してインスペクションを実行するのは面白そうですが、サポートでは多くの問題が発生します。 Android Studio のバージョンを更新すると、理解できないバグとの戦いが必要になります。 また、ライブラリがあまり安定しておらず、誤検知があったため、スクリーンショット テストをサポートすることも困難でした。 スクリーンショット テストがチェック リストから削除されました.

その結果、次のものが残りました。

• ARK アセンブリ。
• Junit テスト。
• 計装テスト。

Gradleリモートキャッシュ

厳しいチェックがなければ、すべてが改善されました。 しかし、完璧には限界がありません。

私たちのアプリケーションはすでに約 150 の Gradle モジュールに分割されています。 通常、この場合は Gradle リモート キャッシュがうまく機能するため、それを試してみることにしました。

Gradle リモート キャッシュは、個々のモジュール内の個々のタスクのビルド アーティファクトをキャッシュできるサービスです。 Gradle は、実際にコードをコンパイルする代わりに、HTTP を使用してリモート キャッシュをノックし、誰かがすでにこのタスクを実行したかどうかを尋ねます。 「はい」の場合、結果をダウンロードするだけです。

Gradle は Docker イメージを提供するため、Gradle リモート キャッシュの実行は簡単です。 なんとかXNUMX時間でこれを終えることができました。

Docker を起動してプロジェクトに XNUMX 行記述するだけで済みました。 ただし、すぐに起動できても、すべてがうまく機能するまでにはかなりの時間がかかります。

以下はキャッシュミスのグラフです。

当初、キャッシュ ミスの割合は約 65 でした。20 週間後、この値を XNUMX% まで増やすことができました。 Android アプリケーションが収集するタスクには、Gradle がキャッシュを逃したため、奇妙な推移的な依存関係があることが判明しました。

キャッシュを接続することで、ビルドが大幅に高速化されました。 しかし、組み立てに加えて計装テストもあり、それには長い時間がかかります。 おそらく、すべてのプル リクエストに対してすべてのテストを実行する必要があるわけではありません。 これを調べるために、影響分析を使用します。

影響分析

プル リクエストでは、git diff を収集し、変更された Gradle モジュールを見つけます。

変更されたモジュールとそれに依存するすべてのモジュールをチェックするインストルメンテーション テストのみを実行するのが合理的です。 隣接するモジュールのテストを実行することに意味はありません。そこにあるコードは変更されておらず、何も壊れることはありません。

インストルメンテーション テストは、最上位のアプリケーション モジュールに配置する必要があるため、それほど単純ではありません。 各テストがどのモジュールに属しているかを理解するために、バイトコード分析によるヒューリスティックを使用しました。

関連するモジュールのみをテストするようにインストルメンテーション テストの動作をアップグレードするには、約 XNUMX 週間かかりました。

検査を迅速化するための措置が奏功した。 45 分から 15 分くらいまで伸びました。ビルドに XNUMX 分待つのはすでに普通のことです。

しかし現在、開発者たちは、どのビルドが起動されているのか、ログはどこで確認できるのか、なぜビルドが赤色なのか、どのテストが失敗したのかなどがわからないと不満を漏らし始めています。

フィードバックに関する問題は開発の速度を低下させるため、各 PR とビルドについてできるだけ明確で詳細な情報を提供するように努めました。 まずは Bitbucket で PR にコメントし、失敗したビルドとその理由を示し、ターゲットを絞ったメッセージを Slack に書きました。 最終的に、現在実行中のすべてのビルドとそのステータス (キューに入れられている、実行中、クラッシュまたは完了) のリストを含むページの PR ダッシュボードを作成しました。 ビルドをクリックすると、そのログにアクセスできます。

詳細なフィードバックに XNUMX 週間を費やしました。

予定

最近の歴史に移りましょう。 フィードバックの問題を解決したことで、私たちは新たなレベルに到達しました。独自のエミュレータ ファームを構築することにしました。 テストやエミュレータが多数あると、管理が難しくなります。 その結果、すべてのエミュレーターは柔軟なリソース管理を備えた k8s クラスターに移行されました。

この他にも企画がございます。

• 糸くずを返す (およびその他の静的分析)。 私たちはすでにこの方向に取り組んでいます。
• PR ブロッカーですべてを実行する エンドツーエンドのテスト すべての SDK バージョンで。

そこで、Avito における継続的インテグレーションの開発の歴史をたどってきました。 ここで、経験豊富な観点からいくつかのアドバイスをしたいと思います。

Советы

一つだけアドバイスできるとしたら、次のようになります。

シェルスクリプトには気をつけてください！

Bash は非常に柔軟で強力なツールであり、スクリプトを作成するのが非常に便利で高速です。 しかし、それは罠にはまる可能性があり、残念ながら私たちはその罠に陥ってしまいました。

すべては、ビルド マシン上で実行される単純なスクリプトから始まりました。

#!/usr/bin/env bash
./gradlew assembleDebug

しかし、ご存知のとおり、時間の経過とともにすべてが発展し、より複雑になっていきます。あるスクリプトを別のスクリプトから実行して、そこにいくつかのパラメーターを渡しましょう。最終的には、現在 bash のネストがどのレベルにあるのかを決定する関数を書かなければなりませんでした。必要な引用符を挿入して、すべてを開始します。

このようなスクリプトの開発にかかる人件費は想像できるでしょう。 この罠に陥らないようにアドバイスします。

何が置き換えられますか?

• 任意のスクリプト言語。 書き込み先 Python または Kotlin スクリプト スクリプトではなくプログラミングであるため、より便利です。
• または、すべてのビルドロジックをフォームに記述します カスタムgradleタスク あなたのプロジェクトのために。

私たちは XNUMX 番目のオプションを選択することに決め、現在、すべての bash スクリプトを体系的に削除し、多くのカスタム Gradle タスクを作成しています。

ヒント #2: インフラストラクチャをコードに保存します。

継続的インテグレーション設定は、Jenkins や TeamCity などの UI インターフェイスではなく、テキスト ファイルの形式でプロジェクト リポジトリに直接保存される場合に便利です。 これによりバージョン管理が可能になります。 コードをロールバックしたり、別のブランチにビルドしたりすることは難しくありません。

スクリプトはプロジェクトに保存できます。 環境をどうするか？

ヒント #3: Docker は環境を整えるのに役立ちます。

Android 開発者にとっては間違いなく役立ちますが、残念ながら iOS にはまだありません。

これは、jdk と android-sdk を含む単純な docker ファイルの例です。

FROM openjdk:8

ENV SDK_URL="https://dl.google.com/android/repository/sdk-tools-linux-3859397.zip" 
    ANDROID_HOME="/usr/local/android-sdk" 
    ANDROID_VERSION=26 
    ANDROID_BUILD_TOOLS_VERSION=26.0.2

# Download Android SDK
RUN mkdir "$ANDROID_HOME" .android 
    && cd "$ANDROID_HOME" 
    && curl -o sdk.zip $SDK_URL 
    && unzip sdk.zip 
    && rm sdk.zip 
    && yes | $ANDROID_HOME/tools/bin/sdkmanager --licenses

# Install Android Build Tool and Libraries
RUN $ANDROID_HOME/tools/bin/sdkmanager --update
RUN $ANDROID_HOME/tools/bin/sdkmanager "build-tools;${ANDROID_BUILD_TOOLS_VERSION}" 
    "platforms;android-${ANDROID_VERSION}" 
    "platform-tools"

RUN mkdir /application
WORKDIR /application

この Docker ファイルを作成し (秘密をお教えします。作成する必要はありませんが、既成のファイルを GitHub からプルするだけです)、イメージをアセンブルすると、アプリケーションを構築できる仮想マシンが得られます。そして Junit テストを実行します。

これが理にかなっている主な理由は、スケーラビリティと再現性の XNUMX つです。 docker を使用すると、以前のものとまったく同じ環境を持つ XNUMX 個のビルド エージェントをすばやく起動できます。 これにより、CI エンジニアの作業が大幅に楽になります。 android-sdk を docker にプッシュするのは非常に簡単ですが、エミュレータの場合は少し難しくなります。少し苦労する必要があります (または、完成したものを GitHub から再度ダウンロードする必要があります)。

ヒントその 4: 検査は検査のために行われるのではなく、人々のために行われることを忘れないでください。

開発者にとって、何が壊れたのか、どのテストが失敗したのか、ビルドログはどこで確認できるのかなど、迅速かつ明確なフィードバックが非常に重要です。

ヒント #5: 継続的インテグレーションを開発するときは、現実的になってください。

どのような種類のエラーを防止したいのか、どのくらいのリソース、時間、コンピュータ時間を費やしてもよいのかを明確に理解します。 たとえば、時間がかかりすぎるチェックは一晩延期される可能性があります。 そして、それほど重要ではないエラーをキャッチしたものは完全に放棄されるべきです。

ヒント #6: 既製のツールを使用します。

現在、クラウドCIを提供する企業は数多くあります。

これは小規模なチームに適したソリューションです。 何もサポートする必要はなく、少額のお金を支払うだけでアプリケーションを構築し、インストルメンテーション テストを実行することもできます。

ヒント #7: 大規模なチームでは、社内ソリューションの方が収益性が高くなります。

しかし、遅かれ早かれ、チームが成長するにつれて、社内ソリューションの収益性はさらに高まるでしょう。 これらの決定には XNUMX つ問題があります。 経済学には収穫逓減の法則があります。どのプロジェクトでも、その後の改善はますます困難になり、より多くの投資が必要になります。

経済学は、継続的インテグレーションを含む私たちの生活全体を表します。 継続的インテグレーションの開発の各段階の人件費のスケジュールを作成しました。

改善がますます困難になっていることは明らかです。 このグラフを見ると、チーム規模の成長に応じて継続的インテグレーションを開発する必要があることがわかります。 50 人のチームにとって、内部エミュレータ ファームの開発に XNUMX 日を費やすのは平凡なアイデアです。 しかし同時に、大規模なチームの場合、継続的インテグレーションをまったく行わないことも悪い考えです。統合の問題やコミュニケーションの修正などが必要になるからです。 さらに時間がかかります。

私たちは、人はお金がかかり、間違いを犯し、怠け者であるため、自動化が必要であるという考えから始めました。 しかし、人々は自動化もします。 したがって、すべて同じ問題が自動化にも当てはまります。

• 自動化には費用がかかります。 分娩スケジュールを覚えておいてください。
• 自動化に関しては、人は間違いを犯します。
• すべてがそのように機能するため、自動化するのが非常に面倒になる場合があります。 なぜ他のものを改善する必要があるのでしょうか、なぜこのような継続的インテグレーションを行う必要があるのでしょうか?

しかし、統計があると、アセンブリの 20% でエラーが検出されます。 これは、開発者のコ​​ードの書き方が下手だからではありません。 これは、開発者が何らかの間違いを犯した場合、それは開発に終わらず、自動チェックによって発見されると確信しているためです。 したがって、開発者は、何かをローカルで実行してテストするよりも、コードや興味深いものの作成により多くの時間を費やすことができます。

継続的インテグレーションを実践します。 ただし、ほどほどに。

ちなみに、ニコライ・ネステロフ氏は自ら素晴らしい報告を行うだけでなく、プログラム委員会のメンバーでもあります。 アプリカンファレンス 他の人があなたのために有意義なスピーチを準備できるよう支援します。 次回の会議プログラムの完全性と有用性は、次のトピックによって評価できます。 スケジュール。 詳細については、22 月 23 ～ XNUMX 日に Infospace にお越しください。

出所： habr.com