開発プロセスとCIパイプラインを構築する、またはQAのDevOps開発者になる方法

与えられた：

1. Angularを前面に持つ大規模なJavaプロジェクト、
2. 小さなチーム（〜15人）によって開発されました。
3. フィーチャーブランチのヒープ（並列で約40個）を使用し、
4. gitリポジトリ内;
5. 開発タスクに使用できるプライベートAmazonクラウド内の複数の仮想サーバー。
6. Javaに少しうんざりしていて、プロセスのセットアップに本当に役立つことをしたい開発者。

必須です：

1. QAエンジニアに、各機能ブランチを手動または自動で、他の機能を妨げない専用スタンドでテストする機会を提供します。

QA 宇宙船制御コンソール

だから、アメリカのルーツを持つ小さなスタートアップで働くようになります...

そのようなスタートアップはまだ小さいが、有望な製品と市場を征服する大きな計画がある。

そして最初は、開発チームは非常に小さい（最大10人）のですが、コードベースの開発はGitHub Enterpriseの一般的なリポジトリで行われ、小さな機能の迅速な割り当て、マスターからのブランチ、同じブランチマスターへの機能ブランチの迅速なリリースサイクル。 チームリーダーは、誰が何をコミットしたかを追跡することができ、各コミットは読み取りだけでなく、それが正しいかどうかも理解します。 したがって、プルリクエストが開かれ、開発者自身が口頭で口頭で承認する（または拒否する）とすぐにマージされます。

コードベースの整合性を確保するために、チームはユニットテストと統合テストに依存していますが、そのうち数千がすでに記述されており、約60％のカバレッジが提供されています（少なくともバックエンドに対して）。 開発リーダーは、リリース前にマスターでテストのフルサイクルも実行します。

プロセスは次のようになります。

COMMITS»MANUAL TESTS»リリース

数ヶ月が経ちます。 スタートアップは活力を示し、投資により最大15人の開発チームを構築できます。 ほとんどの場合、フロントエンドが登場し、エンドユーザーが見たり使用したりするファサードをすばやく拡大し始めます。 正面は作業中のケシで正面から直接テストされ、Seleniumでいくつかのケースを作成しますが、Seleniumはゆっくりと知られているため、開発リーダーはリリース前にそれらを実行する時間がありません。

そして、文字通り次々と2つのfakapsが発生します。

最初に、バックエンドの1人が誤ってマスターをプッシュします（貧しい男は冷たくなり、その後時間を費やしましたが、それについては考えませんでした）。自分を引っ張ります。

その後、フロンティアが別のブランチで約2か月間開発した主要な機能の1つであり、すべてのUIテストによると、マスターのマージが急激に赤になり、製品全体の作業がほとんどクラッシュした後、緑になります。 独自のAPIの重大な変更を聞いた。 そして、テストはそれらを捕らえるのを助けませんでした。 それは起こります。 しかし、混乱。

そのため、スタートアップの前に、QAチームを設立するという問題、そして実際には、機能ブランチと一般的な開発方法論を規律と連携させるためのルールが完全に提起されています。 また、プルリクエストの前のコードは、開発リーダー（すでにやるべきことがたくさんあります）だけでなく、他の同僚もレビューする必要があることが明らかになります。 一般的な成長の問題。

そこで、「 Given： 」というポイントに至りました。

いいえ、私はビルドエンジニアになるつもりはありませんでした。 しかし、プロジェクトアセンブリの開発と、コーナーのローカル開発者サーバーにインストールされたTeamCityでの単体テストの実行におけるリードの実証に成功した後、誰かがこれをバトルモードに設定する必要がありました。 そして、私は機能の間にいくつかの自由時間を過ごしました。

さあ、始めましょう。

まず、AmazonクラウドでTCヘッドインスタンス（+ 2つの無料エージェント）をセットアップし、それらを切断してGihabaリポジトリでコミットをリッスンします（仮想PRADは各githubで仮想HEADを作成し、変更をリッスンするのは非常に簡単です）。 。 だれかがコミットすると、5分後にアセンブリがキューに入ります。 便利に。

COMMITS»プルリクエスト»ビルド+テスト»リリース

しかし、十分ではありません。

当時のgithubには、プルリクエストを表示するための非常に不快なインターフェイスがあり、コメントを残すこともできませんでした。 それは、スクリーンのフットクロスを浪費しなければならなかったので長すぎます。 つまり、チームメンバーからマージする権利を奪うことは可能でしたが、サードパーティのサービスなしで通常のコードレビューを提供することは不可能でした。 さらに、機能をタスクにアタッチし、タスクを機能自体にアタッチするように、同時にJiraと統合することも望んでいました。

幸いなことに、Atlassianには同様のソリューションがあり、それはBitBucket Serverと呼ばれ、当時はStashとも呼ばれていました。 他のアトラシアン製品とこの統合マジックをすべて実行でき、コードレビューに非常に便利です。 移行することにしました。

しかし、この素晴らしい製品は、githubとは異なり、すべてのPRに仮想HEADを作成するわけではありません。また、移行後は何も聞くことができませんでした。 コミット後のフックも機能しませんでした。これは、全員が適切に対処する時間がないためです。

そのため、当初、キャッシュとTeamCityの統合は、曲がった松葉杖によって行われていました。 フックに夢中になった海外の同僚は、ビルトインREST APIを使用してプルリクエストを表示する代わりに、常にtail -fを中心に展開するログ解析を必死に行い、grepで目的のタイプの変更を探してからRESTをプルしますAPI TC。 最も論理的なアプローチではなく、一部のビルドは2倍になり始めましたが、一度は何ができますか。

将来を見据えて-時間が来たら、stash-watcher.shを人間で書き換え、通常のRESTを介して変更を取得し、JSONレスポンスを優れた強力なjqユーティリティで解析することができました。 -そして、本当に必要な場合にのみTeamCityをプルします。 それと同時に、スクリプトをシステムデーモンに登録して、再起動時に起動されるようにしました。 Amazonianインスタンスをときどき再起動する必要があります。

パズルには2つのピースがあります。

COMMITS»プルリクエスト»コードレビュー|| 建物とテスト»リリース

この間に、QAエンジニアがチームに登場しました。

悪いこと！ 1日間、5つの機能ブランチをローカルで切り替え、それらを手動で収集して実行します！？ はい、あなたは敵にこれを望みません!!!

私は正直に認めます：QAエンジニア（特に女の子）を心から愛しています。 そして、一般的に、私は一人ではありません。 元々単体テストを信じていたニューヨークの同僚でさえ、結局は彼らを愛しています。 しかし、彼らは問題を漠然と定式化したとき、それについても知りませんでした：「あなたは私たちのクラウドのどこかで各ブランチのアプリケーションのインスタンスを自動的に起動できるように、そのような質問を何らかの方法で調査する必要があります、現在開発中の機能で何が起きているのか。 しますか？」

「わかりました」と言いました（まあ、他に誰ですか？かつてDevOpsに参加したのは最後の人です）、「ここにアイテムがあります」 必須：が到着しました。

興味深いタスク。 結局、ビルドに基づいて自動展開を設定することができれば、一気にビジネスと私たちの質の低いQAの両方のニーズを満たすことができます。 アセンブリをローカルで苦しめる代わりに、彼らは完成したコピーのためにクラウドに行きます。

ここで、アプリケーションは、Apache Tomcatの下で実行されるいくつかのWARコンテナで構成されていると言わなければなりません。 WARは、ご存知のように、内部に特別なディレクトリ構造とマニフェストを持つ通常のZIPアーカイブです。 また、アプリケーションをビルドすると、その構成（データベースへのパス、他のWARのRESTエンドポイントへのパスなど）がリソース内のどこかに縫製されます。 そして、TomcatにWARを供給するために、それをconfigsに登録し、どこから、どのURLで、どのポートにデプロイするかを登録する必要があります。

そして、同じWARの多数のインスタンスを一度に開始したい場合はどうでしょうか？ Tomcatをオンザフライで設定して、異なるポートまたはURLに分散しますか？ そして、WARリソース内に配線された構成をどうするか？

質問に対するある種の悪い発言。

だから私たちは他の方法で行きます。 たとえば、IDEAは、デバッガーでWARを開始するときに、コマンドラインキー-Dcatalina.baseを介してtomcatに$TOMCAT_PATH/confディレクトリのコピーへ-Dcatalina.baseパスを$TOMCAT_PATH/conf 、WARを単一のピースではなく、展開された形式で、つまり解凍して、起動できるようにしますファイルをバイトコードに置き換えます。

IDEAの機能を確認した後、このアルゴリズムの繰り返しと改善を試みます。 まず、Amazonクラウドに巨大な仮想インスタンスをセットアップし、数百のディスクスペース（および展開された形式では、アプリケーションは非常に大胆です）とギガバイトのRAMを備えています。

ここでnginxを上げ#####.dev..///REST/endpoint 、HTTPリクエストをアドレス#####.dev..///REST/endpointリダイレクトするルールを確立するのは非常に簡単#####.dev..///REST/endpoint to localhost:#####///REST/endpointおよびその逆。 #####-これはすでに特定のポート番号であり、ボリューム構成で構成されています。 はい、1つのTomcatの下ですべての機能ブランチを実行しようとすることすらありません。代わりに、それぞれに対して個別のディレクトリ$TOMCAT_PATH/confを作成し、Tomcatを実行します。 これは何倍も単純で信頼性が高く、並列性に問題はありません。

異なるコピーで番号が一致しないように、番号を取得する場所を考えます。 ビルド番号？ いいえ、この場合、QAはどのインスタンスがどの機能に属しているかについて混乱します。 同じ理由でリビジョン番号が削除されます。 さて、何もすることはありません。すべての開発者にブランチに名前を付けて、 feature-#####--またはbugfix-#####--基づいてJiraからのタスク番号が必ず含まれるbugfix-#####--ます。 ここに番号の最後の3桁があり、ポート番号に含まれます。 それも美しいです

WARをビルドするtimcityビルドに追加のビルドステップを追加します。これにより、SSHを介して大胆なAmazonianインスタンスがスローされ、以下を実行するbashスクリプトがSSH経由でプルされます。

1. ディレクトリ/ deployments / d ###でWARを展開します。
2. tomcatの/ deployments / skel confディレクトリからコピー、
3. ダンプから単一のデータベースインスタンスのローレットを作成します（データベースダンプはソースツリーにあるため、手元にあります）。
4. awk、sed、grep、findなどの助けを借りて、confのコピーからTomcatの設定を修正する母親、およびWARによって解凍されたリソースの設定を修正して、正しいポート、ベースへのパス、RESTエンドポイント、その他すべてを持つようにします。

その後、 -Dcatalina.base=/deployments/d###スイッチを-Dcatalina.base=/deployments/d###てTomcatを実行するだけで、完了です。

COMMITS»プルリクエスト»コードレビュー|| 建物とテスト»QAインスタンスの展開»QA ENGINEERS TORTURE HIM»リリース

ちょっと待ってください。お気に入りのQAエンジニアが手動でSSHを使用するか、コマンドラインからTomcatを実行しますか？ どういうわけかスーパーではありません。 自動的に拾うこともできますが、機能ブランチは既に60未満であり、太字のインスタンスでもメモリはまだゴムではないため、不便です。 ブレーキがかかります。

考えて、頭、帽子を買う。 あ！ したがって、すべてが/deployments/d###場合は、ルートインスタンスを管理するためのコンソールを作成することもできます。 たとえば、各サブリンクを開始/停止リンクごとに吐き出します。

nginxは既に提起されており、その中にクラシックCGIを構成します-ファイアウォールに関する2バイトのように。 クラシックCGIとは何ですか？ これは、すべてのヘッダーを含むHTTP要求がバイナリの標準入力に送信され、いくつかの環境変数が設定され、HTTP応答がすべてのヘッダーを含む標準出力から取得される場合です。 また、蒸したカブよりも簡単です。これはすべて、文字通り手で行うことができます。

手？ だから私にbashでディレクトリハンドラ/デプロイメントを書かないでください？ おそらくできるからです。 書いて、 list.dev..をlist.dev..方法（すべてのインスタンスのように、スタートアップの内部ネットワークからのみ利用可能になります）...時々、役に立つだけでなく、少し異常なものも欲しいです。 最小限のbash HTTP要求ハンドラーなど。

だから書きました。 実際、awk、sed、grep、findなどの母親の助けを借りて、/ deploysサブディレクトリを実行し、何が何にあるのかを切り離すbashスクリプト。 ビルド番号、リビジョン番号、機能ブランチの名前-これらすべてのゴミなど、念のため、WARニックネームとともにTCからすでに送信されています。

ハーフキックで獲得。 欠点の1つは、 list.dev../refresh?start=d###の形式の入力コマンドをbashレギュレーターとniksovyeユーティリティの助けを借りてlist.dev../refresh?start=d###はあまり便利ではないことです。 しかし、それはすでに自分のせいです-グローバルスラッシュコマンドとインスタンスの疑問符アクションマークを思い付きました。 はい、外部ユーティリティは60のサブディレクトリで何百回も呼び出されたため、コンソールはすぐに動作しませんでした。

一方、特定のインスタンスが標準ps（同じgrepの出力）から実行されているかどうかを判断することもできます。また、たとえばnetstatまたはmysql -e "SHOW DATABASES"をキャッシュレジスタから離れずに呼び出して配置することもできます。読みやすくするために灰色またはavkをわずかに編集することによる標準出力。 診断のために、非常に便利で便利です。

また、食欲は食事に伴うものなので、すぐにkillall -9 javaコマンドがコンソールに表示され（週をゼロから開始することもあります）、稼働時間、およびその他のいくつかの有用性があります。 最も重要なことは、データベースとともにアプリケーションインスタンスを削除する機能です。 クラウンによると、もちろん、/ deploymentsディレクトリは2週間でクリーンアップされます（当初は想定されていました）が、PRリーダーによってリダイレクトされたビルドの絶版コピーを削除したい場合があります。

もう少し時間が経つと、一連のテストケースが大きくなり、QAエンジニアは、大きな機能の完全な回帰サイクルを実行するために、インスタンスデータベースにかなりの数のエンティティを作成する必要があります。 そして、これは一日ではありません。 また、この間に開発者がコードレビューの結果に従って何かをブランチにフィードした場合、インスタンスデータベースはビルド後に再びデプロイされ、エンティティが失われます。 おっと

無効なインスタンスのスナップショットを取得する機能を追加します。 これをgithのリビジョン番号にバインドし（実験の結果によると、数字は非常に一意です）、 /deployments/s### deploys /deployments/s### （プレフィックスの別の文字、インスタンスと画像が異なる名前空間を持つように）に入れます。 都市とほぼ同じスクリプトを使用して展開し、ダンプからではなく、既存のデータベースをコピーします。

そのため、QAエンジニアは青に変わる前に特定のリビジョンをテストする機会を得ます。この間、開発者は必要に応じてメインのリビジョン修正ブランチにコミットできます。 その後、リリース前に、メインインスタンスでのこれらのポイントの変更のみがチェックされます。

COMMITS»プルリクエスト»コードレビュー|| 建物とテスト»QAインスタンスの展開|| 写真QAコピー»QAエンジニアは彼を苦しめます»リリース

わあ！ 混oticとしたプロセスからわずか6か月で、開発者が多くの機能をコミットすると、論理的で調和のとれた継続的統合パイプラインのシステムに行き着きました。各ステップは規制され、各ツールは可能な限り自動化されています。

開発者がPRを作成するとすぐに、テストインスタンスの展開プロセスが既に検討され、開始され、文字通り1時間後に（運がよければ-並行機能ブランチの数はチームの成長とともにすぐに数百に増加し、TCで最大7つのインスタンスを上げる必要がありました）QAが準備できます機能のテストに。 少なくともREST API経由のスクリプトを使用して少なくとも手動で操作し、必要に応じてテストインスタンス管理コンソールを使用して診断し、バグに対処します。

それでは歌詞。 しばらくすると、誰もがコンソールのブレーキに疲れたので、私は若さを覚えて、bash（申し訳ありませんが、この小さなプロジェクトのすべての異常はすぐに失われました）から単純な退屈なPHP（しかし、実際にはそのようなタスクを行うのはJavaではありません）に書き直さなければなりませんでしたが、フロンティアの1つは、旧式のプレーンHTMLから完全に最新のAngularアプリケーションにUIをリメイクできました。 しかし、私はただ楽しみのために、インターフェースを90年代に維持することを主張しました。 Tomcatでstdoutとstderrを表示する機能が追加されました。 REST APIをその場で呼び出すための特別なCLIインターフェースを作成し、少し便利なものもいくつか作成しました。

非常に快適なことが判明しました。


QAエンジニアリングチームの幸せそうな顔を見てください！