Positive Technologiesでは、さまざまなITシステムのセキュリティ調査を実施するだけでなく、脅威の検出と防止を支援し、起こりうる攻撃による被害を最小限に抑える製品を開発しています。
過去数年にわたって、当社の製品ラインは劇的に拡大しました。アプリケーションレベルのファイアウォールからインシデント管理ツールまで、市場で多くの人々に知られている多くの新しいツールがMaxPatrolシステムに追加されました。 このような開発により、社内の開発プロセスを適応させる必要性に直面しました。そのため、DevOpsプラクティスと関連テクノロジーを作業に積極的に導入しています。
今日は、作成した継続的インテグレーションシステムのモデルについてお話したいと思います。
背景
何年も前に、コードのアセンブリとテストを自動化するための継続的インテグレーションシステムとしてTFSツールを選択しました。 時間が経つにつれて、このシステムには多くの欠点があることが明らかになりました。 特に、使用する場合：
- アセンブリ、展開、およびテストの構成パターンを維持することは困難です。
- ＃C以外のプロジェクトの統合に問題があります。
- インフラストラクチャの不可能な急速な拡大。
使用期間が長くなるほど、すべてのタイプの構成の作成を入力および標準化する必要性、継続的インテグレーションシステムでの標準プロジェクトの作成を加速する必要性、および新しい構成の追加の簡素化によるプロジェクトの拡張性の確保がより深刻になりました。
これらの問題を解決するには、ほぼ2年かかりました。 Positive Technologiesでの継続的インテグレーションインフラストラクチャは次のとおりです。 これは、3つの基本サービスの束で構成されています。
- TeamCityは、継続的インテグレーションの主要な組織システムです。
- GitLabはソースコードストレージシステムです。
- Artifactoryは、コンポーネントと製品の収集されたバイナリバージョンを保存するためのシステムです。
継続的インテグレーションシステムの標準プロジェクトの開発に特に注意を払いました。 これにより、いわゆるリリースアセンブリスキームをTeamCityのプロモーションで強調することで、プロジェクトの統合を達成できました。
仕組みは次のとおりです。 すべてのプロジェクトは同じように見えます。アーティファクトに分類されるアセンブリの構成が含まれ、その後、プロジェクトのリリースリポジトリに展開、テスト、および昇格されます。
その結果、すべてのプロジェクトには標準の3レベルの組織があります。 最初のレベルはプロジェクトレベルです。たとえば、TeamCityでは、すべての種類のアセンブリテンプレートがこのレベルで格納され、その後に共通製品のさまざまなコンポーネントを含むサブプロジェクトレベルが格納されます。各サブプロジェクトには、アセンブリ、展開、テスト、およびツールの標準構成グループが含まれます
その結果、TeamCityのすべてのプロジェクトは同じ階層を持ち、非常に便利です。 詳細についてはこちらをご覧ください 。
結果は何ですか
ほぼ2年にわたって継続的インテグレーションシステムを開発してきましたが、現時点では次のように見えます。 アセンブリのアセンブリ、展開、テスト、およびプロモーション用の標準構成グループに加えて、テスト済みのリリースアセンブリをグローバルアップデートサーバーに公開するシステムを追加し、そこからさらに顧客のインフラストラクチャに配布します。
2016年のPositive Technologiesの継続的統合プロセスの高レベルIDEF0モデル。 写真をクリックすると、フルサイズで開きます
さらに、Docker、SaltStack、TeamCity、Teampass、TestRail、VMware、Zabbixなど、他の多くのテクノロジーを使用しています。
ただし、統一のすべての利点にもかかわらず、最初の段階で作成したシステムにも欠点がありました。
それほど単純ではない
まず第一に、TeamCityの構成のロジックは非常に複雑であることが判明し、作業が困難になりました。 これらの構成のサポートは会社のDevOpsチームによってのみ行われ、この形式で作業する場合、プロジェクトのスケーリングの限界にすぐに達しました。 ただし、この問題は、標準プロジェクトの自動生成用のスクリプトを作成することで部分的に解決されました。
また、継続的インテグレーションシステムに統合された製品の配信とインストールのメカニズムもありませんでした。 また、アセンブリサーバーと開発者のマシンでのアセンブリプロセスが異なり、それらの「同一性」を保証できなかったという事実も不便さの原因でした。
私たちのシステムに進み、開発する必要があることが明らかになりました。
計画
TeamCityに基づいて、WindowsおよびLinux用のマシンの2つのアセンブリプールを作成する予定です。 CrossBuilderと呼ばれるアセンブリプロセス最適化システムのさらなる開発も検討されています。 その助けを借りて、多くの問題を解決することが可能になります。
- ビルドサーバーと開発マシンで同じアセンブリプロセスを確保します。
- さまざまなCIシステムを使用する機能。
- 特別なマニフェストファイルを使用したビルドプロセスの宣言的な記述が開発チームに委任され、DevOpsスタッフの時間を節約できます。
これらの問題を解決することで、継続的インテグレーションシステムの効率をさらに高めることができます。
今日は以上です。見てくれてありがとう！ コメントでは、私たちの決定についてのコメントを聞いて喜んで、継続的インテグレーションシステムの構築におけるあなたの経験を共有します！
PS継続的インテグレーションシステムに関するストーリーは、最近モスクワで開催されたDevOpsミーティングの一部として発表されました。
ビデオ：
スライド：
リンクには、イベント中に提示された16のレポートのプレゼンテーションが表示されます。 このトピック発表の最後に、すべてのプレゼンテーションとビデオプレゼンテーションがテーブルに追加されます。
Timur Gilmullin による投稿