継続的インテグレーションを使用してAndroidアプリケーションの開発を整理する方法についての一連の記事でお伝えしたいと思います。 CIの人気にもかかわらず、初心者でも英語でもロシア語を話さないようにするための詳細な指示が段階的にインターネット上にまだないことは私にとって驚きでした（まあ、または単に私はそのようなものを見つけませんでした）。
サイクルの最初の記事では、現在の退屈な状況を検討し、救いのための行動計画の概要を説明します。これは、最後に受け取ることを期待しているものであり、私たち全員がそれを目指しています。 そして、徐々に、これを実現し始めます。 興味のある方は、猫の下でお願いします。
以下のツール/テクノロジーのセットに関するすべての例を検討しますが、これは基本的なものではありません。たとえば、GITはMercurialに、TeamCityはJenkinsに簡単に置き換えることができます。
VCS -GIT
テスト -エミュレーター、Android Instrumentation Framework、JUnit、Robotium、Robolectric、Mockito
ビルド -Maven + android-maven-plugin
IDE -IntelliJ IDEA
アーティファクトストレージ -Nexus
CIサーバー -TeamCity
利用可能なもの：
そのため、プロジェクトのソースコードはGITリポジトリにあり、必要なライブラリはそこに保存され、すべてのプロジェクト参加者は1つのメインマスターブランチにコミットし、リリース用のアセンブリはそこから収集されます。 テストの概念はありません。アセンブリはIntelliJ IDEAを使用して実行され
Tools -> Android -> Export Signed Application Package.
。
Tools -> Android -> Export Signed Application Package.
プロセスの参加者間で収集されたアーティファクトは、メール、スカイプなどによって配布されます。 次のリリースバージョンの準備には最大数時間かかる場合があります：構成ファイルの切り替え、アプリケーションのバージョン番号の変更、リポジトリへのリリースのコミット、コミットするバージョン番号のタグの作成、必要に応じてすべてが組み立てられていることの確認、アプリケーションは目的のサーバーを見て必要な署名がされていますキーとか。 そして、すべてのチェックと予防措置にもかかわらず、人的要因を忘れてはなりません。
取得したいもの：
ソースコードはまだGITにあります:)リポジトリ内の分岐モデルは、この作業とこの発言に従って構成されています。これにより、検出されたエラーのテストおよび修正フェーズを考慮することができます。 （将来、これによりTeamCityの構成が容易になり、実際、開発、リリースの準備、およびさらなるサポートが大幅に促進されます）。 依存関係は、アセンブリ中にNexusから自動的に取得されます。 組み立てには2つの方法があります。
- IDEを介して、IDEAを使用してデバッグに接続し、さまざまな実行構成を作成する機能（ローカル開発に便利、個々のテストをすばやく起動するなど）
- maven、ワンクリックまたは完全自動
プロジェクトは3つのモジュールで構成されています。
- ルート -プロジェクトのルートには、他の2つのネストされたモジュールが含まれます
- アプリ -アプリケーションとモジュール。 アプリケーション自体に加えて、JUnitおよびRobolectric単体テスト（要するに、デスクトップJVMでAndroidコードを実行できるライブラリ、Robolectricが含まれています。これは、インストルメンテーションテストを使用したバージョンとは異なり、テストを大幅に高速化します）。
- テスト -統合テストを備えたモジュール。 テストは、テストプラットフォームの標準ツール（ Instrumentation Framework ）またはRobotiumを使用して作成されます。
mavenのビルドスクリプトを使用すると、
development
、
test
、および
production
3つの構成でアプリケーションをビルドできます。対応する設定（サーバーアドレス、遅延とタイムアウト、デバッグフラグなど）が異なります。 アセンブリ中に、ユニットおよび統合テストが実行されます。
CIサーバーは以下のアセンブリを実行します。
- 開発 -開発ブランチのプッシュごと。 アセンブリの目的は、「ファイルをコミットするのを忘れたため、プロジェクトが他のチームメンバーから収集されない」などのエラーをできるだけ早く検出することです。
- ナイトリービルド-3つの構成すべてをゼロからビルドし、テストを実行します
- UAT-テスト中にリリース候補を収集し、見つかったバグを修正するアセンブリ
- リリース -市場に投入するためのリリーステストアセンブリ
UATまたはリリースビルドが成功する
rcX.XX-X
に、
rcX.XX-X
または
vX.XX
形式のタグがそれぞれリポジトリに作成されます。 ビルドが圧倒される場合：コンパイルしない、テストの一部が壊れるなど。 -関心のある関係者に警告付きの手紙が送られます。
テストまたは本番環境への展開のための既成のアーティファクトは、プロジェクト参加者がCIサーバーからのみ取得し、手動で転送することはありません。 プロジェクト構成のあるファイルやリポジトリ内のタグの作成について考える必要はありません。すべてが「単独で」行われます。 テストまたはリリースバージョンの新しいリリース候補を準備および構築する時間は2〜5分です。
次の記事では、maven用のpom.xmlを作成し、ゆっくりと計画の実装を開始します
PSHabréの記事を準備している間、このトピックに関する出版物が掲載されましたが、それでも私の経験を書き、共有していきます。