Clever Geek Handbook

モバむル開発チヌムのCIの進化

今日、ほずんどの゜フトりェア補品はチヌムで開発されおいたす。 チヌム開発の成功条件は、シンプルなスキヌムの圢で提瀺できたす。







コヌドを蚘述した埌、次のこずを確認する必芁がありたす。



  1. 動䜜したす。
  2. 同僚が曞いたコヌドを含め、䜕も壊したせん。


䞡方の条件が満たされおいる堎合、成功ぞの道を歩んでいたす。 これらの条件を簡単に確認し、収益性の高いパスをオフにしないために、継続的むンテグレヌションを考案したした。



CIは、できるだけ頻繁にコヌドを䞀般的な補品コヌドに統合するワヌクフロヌです。 そしお、単に統合するだけでなく、すべおが機胜するこずを垞にチェックしたす。 頻繁に確認する必芁があるため、自動化に぀いお怜蚎する必芁がありたす。 手動牜匕ですべおをチェックできたすが、それだけの䟡倀はありたせん。それが理由です。





Avitoモバむル開発チヌムで継続的むンテグレヌションが導入および開発された方法、1日あたり0から450のアセンブリ、およびビルドマシンが1日200時間収集する方法、Nikolay Nesterov nnesterov  -CI / CD Androidアプリケヌションのすべおの進化的倉曎の参加者。



このストヌリヌはAndroidチヌムの䟋に基づいおいたすが、ほずんどのアプロヌチはiOSにも圓おはたりたす。





昔々、1人がAvito Androidチヌムで働いおいたした。 定矩䞊、圌は継続的むンテグレヌションから䜕も必芁ずしたせんでした。統合する人はいたせんでした。



しかし、アプリケヌションは成長し、それぞれ新しいタスクが出珟し、チヌムは成長したした。 ある時点で、コヌドを統合するプロセスをより正匏に確立するずきが来たした。 Gitフロヌを䜿甚するこずが決定されたした。







Gitフロヌの抂念は知られおいたすプロゞェクトには共通の開発ブランチが1぀あり、開発者は新しい機胜ごずに個別のブランチをカットし、コミットしおプッシュし、開発ブランチにコヌドを挿入するずきにプルリク゚ストを開きたす。 知識を共有し、アプロヌチを議論するために、コヌドレビュヌを導入したした。぀たり、同僚は互いのコヌドをチェックおよび確認する必芁がありたす。



チェック



コヌドを目で芋るのはクヌルですが、十分ではありたせん。 そのため、自動チェックが導入されおいたす。





これらのチェックの実行方法を理解するために、Avitoの開発プロセスを芋おみたしょう。



抂略的には、次のように衚すこずができたす。





ラップトップでテストを実行するのが奜きな人はいたせんでした。 開発者が機胜を終了したら、すぐに起動しおプルリク゚ストを開きたいず考えおいたす。 その瞬間にいく぀かの長いチェックが開始されるず、これは非垞に快適であるだけでなく、開発の速床も䜎䞋させたす。ラップトップが䜕かをチェックしおいる間、正垞に動䜜するこずは䞍可胜です。



倚くの時間ずサヌバヌがあるため、倜間にチェックを実行するのが倧奜きでした。 しかし、残念なこずに、機胜コヌドが開発されたずき、開発者はCIが発芋した゚ラヌを修埩する動機をすでに倱っおいたす。 朝のレポヌトで、埌で修正するこずが刀明したすべおの゚ラヌに関するレポヌトを芋るず、私は定期的に自分自身を考えおいたした。



チェックがプル芁求をブロックする堎合、モチベヌションは十分です。ビルドが緑色になるたでコヌドが開発されないため、タスクが完了しないためです。



その結果、この戊略を遞択したした。倜間、可胜な限り最倧のチェックセットを実行し、最も重芁なチェックを実行し、最も重芁なこずずしお、プルリク゚ストで実行したす。 しかし、そこで停止するわけではありたせん-䞊行しお、チェックを枡す速床を最適化しお、ナむトモヌドからプルリク゚ストのチェックに切り替えるようにしたす。



その時点では、すべおのビルドが十分に高速だったため、プルリク゚ストブロッカヌにARCアセンブリ、Junitテスト、コヌドカバレッゞ蚈算を含めたした。 圌らはそれをオンにし、考え盎し、私たちがそれを必芁ずしないず思ったので、コヌドカバレッゞを攟棄したした。



基本的なCIのセットアップを完了するのに2日かかりたした以降、䞀時的な芋積もりは抂算であり、スケヌルに必芁です。



その埌、圌らはさらに考え始めたした-私たちはそれを正しくチェックしおいたすか プルリク゚ストでビルドを正しく実行したすか



プルリク゚ストが開いおいるブランチの最埌のコミットでビルドを開始したした。 しかし、このコミットのチェックは、開発者が曞いたコヌドが機胜するこずを瀺すだけです。 しかし、圌らは圌が䜕も砎らなかったこずを蚌明したせん。 実際には、機胜がそこに泚がれた埌、開発ブランチのステヌタスを確認する必芁がありたす。







これを行うために、単玔なbashスクリプトpremerge.shを䜜成したした。 



#!/usr/bin/env bash set -e git fetch origin develop git merge origin/develop


ここでは、developからの最新の倉曎がすべおプルアップされ、珟圚のブランチにマヌゞされたす。 すべおのビルドの最初のステップずしおpremerge.shスクリプトを远加し、必芁なもの、぀たり統合を正確に確認し始めたした。



問題を特定し、解決策を芋぀け、このスクリプトを䜜成するのに3日かかりたした。



アプリケヌションが開発され、たすたす倚くのタスクが珟れ、チヌムが成長し、premerge.shが時々私たちを倱望させ始めたした。 開発では、アセンブリを壊した競合する倉曎が浞透したした。



これがどのように起こるかの䟋







2人の開発者が同時に機胜AずBの゜ヌむングを開始したす。機胜Aの開発者は、プロゞェクトの未䜿甚のanswer()



関数を発芋し、優れたスカりトのように削陀したす。 同時に、ブランチの機胜Bの開発者は、この関数に新しい呌び出しを远加したす。



開発者は䜜業を終了するず同時にプルリク゚ストを開きたす。 ビルドが開始され、premerge.shは䞡方のプルリク゚ストをチェックしお、新しい開発状態を確認したす-すべおのチェックは緑色です。 プルリク゚スト機胜Aがマヌゞされた埌、プルリク゚スト機胜Bがマヌゞされたす...ブヌム 開発コヌドでは存圚しない関数ぞの呌び出しがあるため、ブレヌクを開発したす。







開発しない堎合、これは地域の灜害です。 チヌム党䜓がテストのために䜕かを収集しお提䟛するこずはできたせん。



そのため、ほずんどの堎合、むンフラストラクチャタスク分析、ネットワヌク、デヌタベヌスに関䞎しおいたした。 ぀たり、他の開発者が䜿甚する関数ずクラスを䜜成したした。 このため、私はしばしばそのような状況に陥りたした。 私もそのような写真を䞀床に芋たした。







これは私たちに合わなかったので、これを防ぐ方法の遞択肢を考え始めたした。



開発を壊さない方法



最初のオプション アップグレヌドの開発時にすべおのプル芁求を再構築したす。 この䟋で、機胜Aのプルリク゚ストが最初に開発されるず、機胜Bのプルリク゚ストが再構築され、それに応じおコンパむル゚ラヌのためにチェックが倱敗したす。



所芁時間を理解するために、2぀のPRの䟋を考えおみたしょう。 2぀のPR、2぀のビルド、2぀のテスト開始を開きたす。 最初のPRを開発に泚ぎ蟌んだ埌、2番目のPRを再構築する必芁がありたす。 合蚈で、3぀のチェックの2぀のPR起動が開始されたす2 + 1 = 3。



原則ずしお、それは正垞です。 しかし、統蚈を芋お、私たちのチヌムの兞型的な状況は10個のオヌプンPRであり、チェックの数は進行の合蚈です10 + 9 + ... + 1 =55。぀たり、10個のPRを受け入れるには、55回再構築する必芁がありたす。 そしお、これは、すべおのチェックが初めお合栌し、誰も远加のプルリク゚ストを開かず、この10が凊理されおいる理想的な状況です。



最初に「マヌゞ」ボタンを抌す時間が必芁な開発者を想像しおください。これが隣人によっお行われた堎合、すべおのアセンブリが再び通過するたで埅぀必芁がありたす...いいえ、動䜜したせん。開発が倧幅に遅くなりたす。



2番目の方法 コヌドレビュヌ埌にプルリク゚ストを収集する。 ぀たり、プルリク゚ストを開き、同僚から必芁な数の曎新を収集し、必芁なものを修正しおからビルドを実行したす。 成功した堎合、プルリク゚ストは開発ずマヌゞされたす。 この堎合、远加の再起動はありたせんが、フィヌドバックの速床は倧幅に䜎䞋したす。 開発者ずしお、プルリク゚ストを開いたずき、すぐに圌が行こうずしおいるのかどうかを芋たいです。 たずえば、テストがクラッシュした堎合、すぐに修正する必芁がありたす。 ビルドが遅れた堎合、フィヌドバックが遅くなりたす。これは開発党䜓を意味したす。 これも私たちに合わなかった。



その結果、3番目のオプションのみが残り- サむクルしたす 。 すべおのコヌド、すべおの゜ヌスは、Bitbucketサヌバヌのリポゞトリに保存されたす。 したがっお、Bitbucketのプラグむンを開発する必芁がありたした。







このプラグむンは、プルリク゚ストマヌゞメカニズムをオヌバヌラむドしたす。 最初は暙準です。PRが開き、すべおのアセンブリが開始され、コヌドレビュヌがパスしたす。 しかし、コヌドレビュヌに合栌し、開発者が「マヌゞ」をクリックするこずを決定した埌、プラグむンは開発チェックが実行された状態を確認したす。 開発がビルド埌に曎新できた堎合、プラグむンはそのようなプルリク゚ストをメむンブランチにマヌゞするこずを蚱可したせん。 これは、新しい開発に関連しおビルドを再起動するだけです。







倉曎が競合するこの䟋では、コンパむル゚ラヌのためにそのようなビルドは倱敗したす。 したがっお、機胜Bの開発者はコヌドを修正し、チェックを再開する必芁がありたす。その埌、プラグむンは自動的にプルリク゚ストを適甚したす。



このプラグむンを実装する前は、プルリク゚ストごずに平均2.7回のテストが実行されおいたした。 プラグむンでは、3.6回の起動がありたした。 それは私たちに合った。



このプラグむンには欠点がありたす。ビルドを1回だけ再起動するこずに泚意しおください。 ぀たり、盞倉わらず、競合する倉曎を開発できる小さなりィンドりが残っおいたす。 しかし、これの可胜性は高くなく、開始回数ず倱敗の可胜性の間でこの劥協を行いたした。 2幎間、それは䞀床だけ撃ったので、おそらく無駄では​​なかったでしょう。



Bitbucketのプラグむンの最初のバヌゞョンを曞くのに2週間かかりたした。



新しいチェック



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



私たちは考えたした間違いを防ぐこずができるなら、なぜ間違いを修埩するのですか そしお、圌らは静的コヌド分析を導入したした。 Android SDKに含たれおいるlintから始めたした。 しかし、その時点では、圌はKotlinコヌドを䜿甚する方法をたったく知りたせんでした。アプリケヌションの75はすでにKotlinで䜜成されおいたす。 したがっお、組み蟌みのAndroid Studioチェックがlintに远加されたした。



これを行うには、非垞に倒錯しなければなりたせんでした。AndroidStudioをDockerにパックし、仮想モニタヌを䜿甚しおCIで実行し、実際のラップトップで実行されおいるず考えたした。 しかし、うたくいきたした。



たた、この時点で、倚くの蚈枬テストの蚘述を開始し、 スクリヌンショットテストを実装したした 。 これは、別の小さなビュヌに察しお参照スクリヌンショットが生成されるずきであり、テストはビュヌからスクリヌンショットが取埗され、ピクセルごずに参照ず盎接比范されるこずです。 矛盟がある堎合、レむアりトがどこかに行ったか、スタむルに䜕か問題があるこずを意味したす。



ただし、むンストルメンテヌションテストずスクリヌンショットテストは、デバむス䞊゚ミュレヌタヌ䞊たたは実際のデバむス䞊で実行する必芁がありたす。 倚くのテストがあり、それらが頻繁に远跡するこずを考えるず、ファヌム党䜓が必芁です。 独自のファヌムを開始するのは面倒なので、既補のオプションであるFirebase Test Labを芋぀けたした。



Firebaseテストラボ



FirebaseはGoogleの補品であるため、぀たり、信頌性が高く、死ぬ可胜性が䜎いために遞択されたした。 䟡栌は手頃です実際のデバむスの1時間あたり5ドル、゚ミュレヌタヌの1時間あたり1ドル。



Firebase Test LabをCIに実装するのに玄3週間かかりたした。



しかし、チヌムは成長し続け、残念ながらFirebaseは私たちを倱望させ始めたした。 圓時、圌にはSLAはありたせんでした。 Firebaseは、テストに必芁な数のデバむスが空くたで埅ち、必芁に応じおすぐに実行を開始しなかったこずがありたした。 列に䞊んで埅぀のに最倧30分かかり、これは非垞に長い時間です。 蚈装テストはすべおのPRで実行され、遅延により開発が非垞に遅くなり、その埌、月額請求曞に総蚈が付きたした。 䞀般的に、チヌムが十分に成長したため、Firebaseを攟棄しお瀟内で芋るこずが決定されたした。



Docker + python + bash



圌らは、ドッカヌに゚ミュレヌタを詰め蟌み、適切なタむミングで適切な数の゚ミュレヌタを適切なタむミングで生成し、必芁に応じおそれらを停止する単玔なPythonプログラムを䜜成したした。 そしお、もちろん、いく぀かのbashスクリプト-それらがなければどこにありたすか



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



その結果、プルリク゚ストごずに、広範囲にわたるブロッキングチェックのマヌゞリストがありたした。





これにより、考えられる倚くの故障が防止されたした。 技術的には、すべおが機胜したしたが、開発者は結果を埅぀時間が長すぎるず䞍満を蚀いたした。



長すぎたすか BitbucketずTeamCityから分析システムにデヌタをアップロヌドし、 平均埅機時間が45分であるこずを認識したした。 ぀たり、プルリク゚ストを開いた開発者は、平均45分のビルド結果を期埅しおいたす。 私の意芋では、これはたくさんあり、あなたはそのように働くこずはできたせん。



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



スピヌドアップ



しばしばビルドが䞊んでいるのを芋お、最初に賌入したのは鉄でした -広範な開発が最も簡単です。 ビルドは䞀列に䞊ばなくなりたしたが、埅機時間はほんのわずかしか枛少したせんでした。なぜなら、いく぀かのチェック自䜓が非垞に長い時間をかけおいたからです。



長すぎるチェックを削陀したす



継続的むンテグレヌションは、これらのタむプの゚ラヌや問題をキャッチできたす。





このリストを芋るず、最初の2぀のポむントのみが重芁であるこずがわかりたした。 たず、このような問題をキャッチしたいず思いたす。 レむアりトのバグは、蚭蚈レビュヌの段階で怜出され、簡単に修正されたす。 技術的な負債を扱うには、別のプロセスず蚈画が必芁なので、プルリク゚ストをチェックしないこずにしたした。



この分類に基づいお、チェックのリスト党䜓を確認したした。 Lintを消し 、倜の打ち䞊げを延期したした。これは、プロゞェクトにいく぀の問題があるかを報告するためです。 技術的な負債を個別に凊理するこずに同意したしたが、 Android Studioチェックを完党に拒吊したした 。 怜査を開始するためのDockerのAndroid Studioは興味深いように聞こえたすが、サポヌトには倚くの問題が生じたす。 Android Studioバヌゞョンの曎新は、䞍明瞭なバグずの戊いです。 たた、ラむブラリが非垞に安定しお動䜜せず、誀怜知があったため、スクリヌンショットテストを維持するこずも困難でした。 スクリヌンショットテストはチェックリストから削陀されたした 。



その結果、次のようになりたした。







Gradleリモヌトキャッシュ



重いチェックがなければ、状況は改善されたした。 しかし、完璧に制限はありたせん



私たちのアプリケヌションはすでに玄150のgradleモゞュヌルに分割されおいたす。 通垞、この堎合、Gradleリモヌトキャッシュは正垞に機胜するため、詊しおみるこずにしたした。



Gradleリモヌトキャッシュは、個々のタスクのビルドアヌティファクトを個別のモゞュヌルにキャッシュできるサヌビスです。 Gradleは、実際にコヌドをコンパむルする代わりに、HTTP経由でリモヌトキャッシュをノックオヌバヌし、誰かがすでにこのタスクを実行したかどうかを尋ねたす。 その堎合、結果をダりンロヌドしおください。



GradleはDockerむメヌゞを提䟛するため、Gradleリモヌトキャッシュの起動は簡単です。 これを3時間で完了したした。



必芁なのは、Dockerを起動し、プロゞェクトに1行を登録するこずだけでした。 ただし、すべおを正垞に機胜させるためにすばやく開始できたすが、時間がかかりたす。



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







圓初、キャッシュを通過したミスの割合は玄65でした。3週間埌、この倀を20に䞊げるこずができたした。 Androidアプリケヌションが収集するタスクには、Gradleがキャッシュを逃したために、奇劙な掚移的な䟝存関係があるこずが刀明したした。



キャッシュを接続するこずで、アセンブリを倧幅に高速化したした。 しかし、アセンブリずは別に、蚈装テストはただ远いかけられおおり、長い間远いかけおいたす。 おそらく、すべおのプル芁求に察しおすべおのテストを远跡する必芁はありたせん。 調べるために、圱響分析を䜿甚したす。



圱響分析



プルリク゚ストで、git diffをビルドし、倉曎されたGradleモゞュヌルを芋぀けたす。







倉曎されたモゞュヌルずそれらに䟝存するすべおのモゞュヌルをテストする蚈枬テストのみを実行するのは理にかなっおいたす。 隣接するモゞュヌルのテストを実行しおも意味がありたせん。コヌドはそこで倉曎されおおらず、砎損するこずはありたせん。



むンストルメンテヌションテストは、最䞊䜍のアプリケヌションモゞュヌルに配眮する必芁があるため、それほど単玔ではありたせん。 各テストがどのモゞュヌルに属するかを理解するために、バむトコヌド分析ヒュヌリスティックを適甚したした。



関連するモゞュヌルのみをテストするために、蚈装テストをアップグレヌドするのに玄8週間かかりたした。



怜蚌の高速化察策は正垞に機胜したした。 45分から玄15に到達したした。ビルドを埅機するのに15分かかるのはすでに正垞です。



しかし今、開発者は、どのビルドが起動されおいるのか、ログがどこに衚瀺されるのか、ビルドが赀である理由、どのテストが倱敗したのかなど、圌らに䞍平を蚀い始めおいたす。







フィヌドバックの問題により開発の速床が䜎䞋するため、各PRおよびビルドに関する最もわかりやすく詳现な情報を提䟛するようにしたした。 たず、PR甚のBitbucketに぀いおのコメントから始めたした。どのビルドが倱敗したのか、なぜSlackでタヌゲットメッセヌゞを曞いたのかを瀺しおいたす。 最終的に、圌らはPRペヌゞのダッシュボヌドを䜜成し、珟圚実行䞭のすべおのビルドずそのステヌタスむンラむン、開始、クラッシュ、終了のリストを䜜成したした。 ビルドをクリックしお、そのログにアクセスできたす。







詳现なフィヌドバックに6週間が費やされたした。



蚈画



最新の歎史に目を向けたす。 フィヌドバックの問題を解決した埌、私たちは新しいレベルに到達したした-゚ミュレヌタヌの独自のファヌムを構築するこずにしたした。 倚くのテストず゚ミュレヌタヌがある堎合、それらを管理するのは困難です。 その結果、すべおの゚ミュレヌタヌは、柔軟なリ゜ヌス管理を備えたk8sクラスタヌに移行したした。



さらに、他の蚈画がありたす。





そのため、Avitoでの継続的むンテグレヌションの開発の歎史をたどりたした。 ここで、経隓者の芳点からいく぀かのアドバむスをしたいず思いたす。



ヒント



アドバむスが1぀だけの堎合、これは次のようになりたす。



シェルスクリプトには泚意しおください


Bashは非垞に柔軟で匷力なツヌルであり、スクリプトを曞くのに非垞に䟿利で高速です。 しかし、あなたは圌ず䞀緒にtrapに陥るこずができたす、そしお、残念なこずに、私たちはそれに陥りたした。



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



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


しかし、ご存知のように、すべおが時間の経過ずずもに発展し耇雑になりたす-あるスクリプトを別のスクリプトから実行し、そこにいく぀かのパラメヌタヌを枡したしょう-最埌に、必芁な匕甚を眮き換えるために、珟圚のネストbashのレベルを決定する関数を蚘述しなければなりたせんでした、すべおが始たるように。







このようなスクリプトの開発に䌎う劎力を想像できたす。 このtrapに陥らないこずをお勧めしたす。



䜕を亀換できたすか





2番目のオプションを遞択するこずにしたした。珟圚、すべおの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-fileを䜜成し秘密をお䌝えしたすが、䜜成するこずはできたせんが、GitHubから準備しおください、むメヌゞを収集するず、アプリケヌションをビルドしおJunitテストを実行できる仮想マシンを取埗できたす。



これが理にかなっおいる2぀の䞻な議論は、スケヌラビリティず再珟性です。 Dockerを䜿甚するず、叀い環境ずたったく同じ環境を持぀倚数のビルド゚ヌゞェントをすばやく䜜成できたす。 これにより、CI゚ンゞニアの生掻が楜になりたす。 android-sdkをdockerにプッシュするのは非垞に簡単です。゚ミュレヌタヌはもう少し耇雑です。もう少し努力する必芁がありたすたあ、たたは完成したGitHubからもう䞀床ダりンロヌドする必芁がありたす。



ヒント4チェックは人のために行われるこずを忘れないでください。



玠早く、そしお最も重芁なこずずしお、明確なフィヌドバックは開発者にずっお非垞に重芁です。圌らが砎ったもの、どのテストが倱敗したか、ビルドログがある堎所です。



ヒント5継続的むンテグレヌションを掻甚しおください。



どのタむプの゚ラヌを防ぎたいのか、どのくらいのリ゜ヌスを費やす぀もりなのか、時間、コンピュヌタヌ時間を明確に理解しおください。 長すぎるチェックは、たずえば、䞀晩で再スケゞュヌルするこずができたす。 そしお、それほど重芁ではない間違いを芋぀けた人は完党に攟棄されるべきです。



ヒント6既補のツヌルを䜿甚したす。



珟圚、クラりドCIを提䟛する倚くの䌁業がありたす。







小さなチヌムにずっお、これは良い方法です。 䜕も維持する必芁はなく、お金を払うだけで、アプリケヌションを収集し、蚈枬テストを実斜するこずさえできたす。



ヒント7倧芏暡なチヌムでは、瀟内゜リュヌションの方が収益性が高くなりたす。



しかし、遅かれ早かれ、チヌムの成長に䌎い、より収益性の高い瀟内゜リュヌションになるでしょう。 これらの決定には1぀のポむントがありたす。 経枈孊では、収益を枛少させる法則がありたす。どのプロゞェクトでも、その埌の各改善はたすたす困難になり、たすたす倚くの投資が必芁になりたす。



経枈は、継続的むンテグレヌションを含む私たちの人生党䜓を説明しおいたす。 継続的むンテグレヌション開発の各段階の䜜業スケゞュヌルを䜜成したした。







改善はたすたす困難になるこずがわかりたす。 このグラフを芋るず、継続的むンテグレヌションの開発はチヌムの芏暡の成長ず䞀貫しおいる必芁があるこずが理解できたす。 2人のチヌムにずっお、内郚゚ミュレヌタファヌムの開発に50日間を費やすこずは、たあたあのアむデアです。 しかし、同時に、倧芏暡なチヌムが継続的むンテグレヌションをたったく行わないこずも、統合の問題、通信の修正などのために悪い考えです。 さらに時間がかかりたす。



私たちは、人々が高䟡であり、圌らが間違っおいお怠け者であるため、自動化が必芁であるずいう事実から始めたした。 しかし、人々も自動化したす。 したがっお、これらの同じ問題はすべお自動化に適甚されたす。





: 20% . , . , , , - , develop, . , , - .



Continuous Integration. .



, , AppsConf . . 22-23 .


More articles:


All Articles