継続的な配信とソフトウェア製品の展開の問題





この記事は、「CI / CD」コースの責任者であるKonstantinBryukhanovによって作成されましたその中で、Konstantinは、IT企業でのソフトウェア製品コードの展開の提供に関連するいくつかの問題点を明らかにし、国際的なベストプラクティスの中から推奨事項を収集しました。






IT運用において最も要求される方向性は、継続的な配信と展開の正確な調整と提供です。テクノロジーと方法論は絶えず進化しており、ツールは改善されています。したがって、最新の配信と展開の要件には、変更テストの準備と継続性、QAチームのテスト環境の準備とセットアップが含まれます。



技術的な進歩と無料のソフトウェアにより、CI / CDプロセスの編成方法に大きな変化がもたらされました。新しい原則への移行は、企業文化、従業員の需要の高いスキル、組織で働くという原則そのものに大きな影響を与え、ソフトウェア開発の世界に大規模な変化をもたらしました。



クラウドソリューションはますます優先されています。継続的なソフトウェア配信には、開発、テスト、運用の各チーム間の効果的なコラボレーションが必要です。クラウドはこのコラボレーションに最適です。



ただし、複雑な分散トポロジで実行される展開フェーズはエラーが発生しやすく、通常は手動によるトラブルシューティングが必要です。継続的な配信プロセスの製品展開フェーズでは、ボトルネックが発生し、DevOpsプロセスの有効性に悪影響を与えることがよくあります。



継続的な配信により、ソフトウェアの増分変更のテストの自動化と、最も効率的かつ安全な方法での更新の迅速な展開を実現できます。このアプローチにより、ユーザーはコードの最新バージョンが実稼働環境で使用されていることを確信でき、プログラマーが行った変更は数時間または数分で顧客に届く可能性があります。



プロジェクトにCI / CDを実装するための最も一般的なシナリオを考えてみましょう。



  1. 開発チームは、製品の新しいバージョンをリリースします(以前のリリースからの新しい機能またはバグ修正)。
  2. 継続的統合(CI)サービスは、構文、ユニット、回帰テストなど、複数レベルのテストを含む一連のテストで新しいコードを検証します。
  3. , (CD).
  4. (, ) , (staging), , .
  5. stage- CI/CD , .
  6. .




このシナリオは最も一般的であり、開発チームと運用チームのニーズのほとんどをカバーしますが、それでもいくつかの問題があります。たとえば、次のようになります。



  1. ファイルの置き換え多くの場合、構成ファイルを更新または置換するか、静的コンテンツを再生成する必要があります。この場合、トラフィックが古いソフトウェアバージョンから新しいバージョンに切り替わるまで、ユーザーはエラーを受け取る可能性があります。展開が失敗した場合、ファイルの非互換性のリスクがあります。
  2. . , , . . , - , - .
  3. . . , , .. . , - , , .. .




上記の問題は理想に近い環境でも発生する可能性があることは注目に値しますが、DevOps手法を実装する際の主な問題のひとつは、継続的な配信と製品の展開プロセスがどのように見えるかについての単一の図がないことです。多くのIT企業はDevOpsについてほとんど知らず、この方法論をまったく理解していない場合もありますが、他の企業はすでに歴史的なソリューションを持っており、その上に新しいプロセスを構築する必要があります。 Devopsスペシャリストの資格に対する高い要件と、労働市場における彼らの不足を考慮して、雇用主はしばしば、すでに自由に使えるリソースを使用し、Devopsのタスクを初心者エンジニアに与えることを余儀なくされます。その結果、システムにはさらに多くの弱点があります。



方法論を正しく理解せずに、コードを配信するためのインフラストラクチャと方法を構築するための分析的アプローチなしにCI / CDを使用すると、次の問題が発生します



。1。人的要因。最初の最も重要なリスクは、人的要因に関連しています。既存のサーバーと同様に、さらにいくつかのサーバーを構成する必要がある状況を想像してみてください。以前のインストールまたは設定を行ったスペシャリストが何らかの理由(病気、終了など)で現在利用できず、詳細な手順を準備していない場合、状況はさらに複雑になります。この場合、新しいスペシャリストはそれぞれ、サーバーをセットアップするプロセス全体を完全に調査する必要がありますが、エラーの余地はありません。また、セットアップと成功の保証にかかる時間を正確に見積もることは不可能です。



これには、メソッドの作成者がミスを犯した、プロセスをテストでカバーするのを忘れた、または単に何かを考慮しなかった、そして彼の後継者がそれに気づかなかったという事実に関連するリスクも含まれます。



また、企業は複数のプロジェクトを開発することが多く、IT運用部門は通常1つであり、1人の運用エンジニアが複数のプロジェクトにサービスを提供することも覚えておく必要があります。単一のスキームとコンセプトがない場合、さまざまなチームのプロセスがさまざまな方法で構築されるため、社内でのDevopsのその後の開発が大幅に複雑になり、運用エンジニアが別のプロジェクトに参加するための高いしきい値が作成されます。このプロジェクトでは、彼が作業したプロセスとは異なるプロセスがすでに使用されています。ついさっき。



2.非理想的なシナリオ..。独立性は、特にインフラストラクチャの展開において、継続的な配信とコードの展開シナリオの重要な属性です。エンジニアは、スクリプトが実行されるたびに、同じスクリプトを再生しても、結果が一意に保証され、期待され、変更されないことを確信している必要があります。多くの場合、企業にDevopsを実装する場合、エンジニアはビジネスソリューションを開発しようとしており、独立性を考慮していないか、単にこの要件について知らない場合があります。この場合、会社は時限爆弾を受け取ります。予期しないコードが生産施設に配信される可能性があります。たとえば、誰かが1つのプロジェクトのCMSモジュールを更新し、それによって他のプロジェクトに影響を与えた場合、これは予期されていません。



3.機密データの保存とアクセスの編成。秘密データの保存、権利の制限、ネットワークとユーザーアクセスの整理に対する、Devopsアプローチの最も重要なポイントの1つ。これまで、この問題を解決するための統一された慣行やツールはなく、エンジニアは、インフラストラクチャの現在の組織と採用されているアクセス制限方法に応じて、毎回調査を行う必要があります。このため、企業でのDevops手法の実装は、特定のケースの解決策を明確に見つけることが不可能であり、他の人の慣行を使用しても必ずしもセキュリティが保証されるとは限らないという事実によって複雑になります。



4.ウォーターフォール手法により適した、定義済みの予算編成モデル



5.高い安全要件。したがって、国内のITプロジェクトのインフラストラクチャを、Amazon、Microsoftなどの商用の外国企業の責任の領域に配置することは不可能です。



6.維持する必要のある大量の「レガシーコード」、「レガシーインフラストラクチャ」。多数のレガシーシステムとの統合の必要性。



したがって、企業でDevopsを構築するプロセスには多くの問題が伴う可能性があり、それが作成された問題を常に解決するとは限りません。



最初の重要なステップは、サーバーとの関係を、カスタマイズが難しく、インフラストラクチャの独自の要素として放棄することです。、手動サーバー構成から自動化された集中型インフラストラクチャ管理への移行。各サーバーの構成プロセスは、読みやすく、変更可能で、複数の安全な再利用に対応できる構成の形式で記述し、明確な保証結果を提供する必要があります。産業用オーケストレーターシステムの例は、ChefまたはAnsibleです。これらのシステムを使用すると、最小限のコストで多数のサーバーを管理できます。



次の重要なステップは、自動テスト適用することです開発中のコードの機能(ソフトウェアとインフラストラクチャの両方)を可能な限りカバーするため。言い換えると、インフラストラクチャが展開されているが、自動テストがない場合、開発プロセスのボトルネックは機能のタイムリーな検証になります。テストプロセスの自動化は、ソフトウェアコードの実際の記述(ユニットテスト)、ソフトウェアの構築を担当するサーバーでのプライマリテストの適用、およびサーバー構成のテストから開始する必要があります。これにより、ソフトウェア品質保証チームの作業負荷が軽減され、ソフトウェアがパイプラインを通過する時間が大幅に短縮されます。



最後の論理的なステップは、すべてのサーバーからのログファイルの集中収集と分析です。すべての利害関係者にタイムリーに通知し、インフラストラクチャ全体の状態をプロアクティブに監視します。



上記のガイドラインは、集中的な開発プロセスを処理できる、回復力がありスケーラブルなインフラストラクチャを構築するのに役立ちます。 DevOpsの実装には、テストと開発からマネージャーと運用に至るまで、プロセスに全員が関与する必要があります。構成変更時のランダムエラーの結果、システムの動作が完全に停止するため、各段階でプロセスの継続的な遡及的分析が必要です。エラーの検出と回復を改善し、展開パイプラインを保護して管理変更の目標を達成するには、テレメトリを改善する必要があります。これにより、DevOpsイニシアチブの実装においてリーダーシップから最大限のサポートを受け、より活気に満ちた、よりフレンドリーな作業環境を作成できます。参加者がいつでも学ぶことができるように、これは各パフォーマーが目標を達成するのに役立つだけでなく、組織を成功に導くことにもなります。



私たちの上の3ヶ月でオンラインコース「CI / CD」あなたは、クラウド・プロバイダーのアーキテクチャの理解を開発したコード分析を自動化し、脆弱性を探し、そして三の大プロバイダからアプリケーションを構築するテストおよびインストールのプロセスをカスタマイズする方法を学習する方法を学習しますこのプログラムは、管理の経験を持つ専門家向けに設計されています。特別な入場テストは、トレーニングの準備が十分にあるかどうかを確認するのに役立ちます。






続きを読む:






All Articles