製品が開発および成長するにつれて、さまざまな困難が生じる可能性があります。 MaxPatrolシステムで作業している間、プロジェクトインフラストラクチャのサポートを担当するチームのリソースの枯渇に直面しました。 特に、展開システムを確立する必要がありました-これは簡単ではありませんでした。 本日は、ディストリビューションを作成するための独自のツールを開発することで、まさに困難とは何か、そしてそれらをどのように克服したかについてお話します。
ちょっとした歴史
2013年のプロジェクトのインフラストラクチャは次のとおりです。
- 1つの製品コンポーネント。
- 1つのインストーラープロジェクト。
- 6サービスおよび構成ファイル。
- 配布用の4つのアーティファクトソースファイル。
- 製品チームの1人がインストーラーの開発に関与しました。
製品開発の過程で、はるかに大きくなっています。 個別のコンポーネントの数が増加し、それぞれでインストーラーパッケージの数が増加し、個々のインストーラーの複雑さが増加し、ファイルソースが増えました。 特別な製品インフラストラクチャ部門を作成する必要がありました。 2014-2015年の数値：
- 4つの製品コンポーネント。
- 18インストーラープロジェクト;
- 20以上のサービスと構成ファイル。
- 50以上のアーティファクト。
- 1つのリリースで〜10の機能ブランチ（FB）。
- 新製品インフラストラクチャ部門の4人。
これはすべて、インフラストラクチャチームの人件費の増加につながりました。システムがより複雑になったため、変更を行う場合、それらを正しく実装する方法を理解するのに時間を費やす必要がありました。 その結果、変更の平均待機時間が増加しました。
私たちは多くの時間を費やしました-各変更は顧客と議論する必要があり、バグは展開段階で対処する必要がありましたが、そのすべてがインストーラーの作業に関連しているわけではありませんでした 同時に、変更には常に高い優先順位があります。つまり、プロジェクトインフラストラクチャを開発するのではなく、この「トリクル」を掻き集めることにもっと対処する必要がありました。
その結果、更新プログラムの配信、一元化された展開管理と構成、インストールパッケージを作成するためのツールなどのインフラストラクチャの側面の開発が大幅に遅くなりました。
ソリューション：責任の分離
開発を最適化するために、インフラストラクチャ開発チームと製品開発チームの責任領域を区別することにしました。 これを正確に行う方法を理解するために、分析を実施しました。 彼は、すべての変更要求をいくつかのグループに分割することを許可しました。
- コンポーネントインストーラーの構成を変更する -どのアーティファクトからどのファイルをインストーラーに取り込む必要がありますか？
- コンポーネント設定の変更 -どのパラメーターを構成する必要があり、どの構成ファイルとどのようにパラメーターを記述する必要がありますか？
- ターゲットオペレーティングシステムの必要な状態の変更 —作成する必要があるサービス、サイト、ファイアウォールルール、スケジューラーのタスク、ディレクトリ（および権限）
その結果、さまざまなタスクの分散が大幅に変更されました。インフラストラクチャチームによるこれらの3つのクラスの問題の独占的な所有権から、混合スキームに移行しました。
ただし、責任分担に同意するだけでは十分ではありません。技術的に実装する方法を見つける必要があります。
DSLによる救助
ドメイン固有言語またはDSLは、特定のタスクで作業するときに使用するのに適した言語です。 私たちのプロジェクトについて話すと、DSLの助けを借りて「同意」し、開発に関与するすべての人が製品の詳細（設定ファイルの変更方法など）を深く掘り下げることなく問題を解決できるツールを手に入れることができました）その結果、作業が大幅に加速され、すべてのエンティティを自由に拡張できるため、柔軟性が向上します。
この段階で使用したテクノロジーは次のとおりです。
- Python（Jinja2、PyYaml、jsonschema） ：スクリプトおよび構成ファイルの生成、DSL記述の検証、スキームのドキュメントの生成。
- PowerShell ：Windows用の展開スクリプト。
- C＃ ：Windows環境をセットアップするための関数の自己記述ライブラリ。
- WiX、MSI ：Windows用のインストールパッケージの作成。
最終的な図は次のようになりました。実際には、DSLとスクリプトテンプレートを使用して、最終的なスクリプトを生成しました。
DSL（Yaml）の使用：
展開シナリオの説明（Jinja2）：
出力はPowerShell展開スクリプトです。
構成ファイルの作成も同様の方法で行われます。最初に、DSLの助けを借りて、パラメーター値が記述され、次に構成ファイルのテンプレートが作成されます。
ドキュメントの生成作業も進行中です。最初にDSLスキームが開発され、次にHTMLドキュメントテンプレートが作成されます。これにより、HTMLで既製のドキュメントを取得できます。
結果と計画
実装の主な成果の1つは、開発者とプロジェクトインフラストラクチャスペシャリストの間で責任が適切に分散されたことです。
2番目の重要な効果：製品に関係する人々の間で、知識が再配布されました。 特に、開発者は展開プロセスについてより多くのことを学びました-インストーラーの説明と構成テンプレートはプロジェクトに直接含まれています。
また、変更の待ち時間を大幅に短縮することができました。 以前は、プロセスは次のようになりました。
このスキームでは、タスク数の増加により生産性が常に低下しました。 この問題は、インフラストラクチャ部門を拡張することで部分的に解決できますが、この方法には適用性の明らかなフレームワークがあります。 そして、常に人よりも多くのタスクがあります。
新しいアプローチの導入後、相互作用スキームは次のようになり始めました。
その結果、変更を行う時間は常に同じであり、特定の問題を解決する必要がある顧客の数から増加することはありません。
そこで停止するつもりはなく、システムを開発する予定です。 近い将来に行われることは次のとおりです。
- 別のターゲットプラットフォームとしての Linux-Linux固有のOSエンティティを記述するためにDSLを拡張し、パッケージの記述に基づいて.debビルドのサポートを実装します。
- SaltStackとの統合 -スクリプトテンプレートはソルトステートに置き換えられます。
- オープンなDevOpsHQコミュニティの GitHubでツールを公開します 。
PSディストリビューションを作成するために開発したツールに関するストーリーは、最近モスクワで開催されたDevOpsミーティングの一部として紹介されました。
リンクには、イベント中に提示された16のレポートのプレゼンテーションが表示されます。 このトピック発表の最後に、すべてのプレゼンテーションとビデオプレゼンテーションがテーブルに追加されます。
投稿者 ： ウラジミール・セリン
PPS私たちは、Positive Technologiesの支援により、Pythonコア開発者のAndrei Svetlov によるasyncio + aiohttpのコースがモスクワですぐに開催されることをお知らせします。
Andreyにとって最高の質問の著者にセミナーの無料チケットを1つ提供したいと考えています。彼はレッスン中に質問を選択して回答します。 質問はasyncio2016@ptsecurity.comに送信してください。