あなたの会社が DevOps または CI/CD ツールを実装しているだけの場合は、最も一般的な間違いを理解し、同じ間違いを繰り返して他人の熊手を踏まないようにすることが役立つかもしれません。
チーム 記事を翻訳しました .
文化やプロセスを変えることを望まない
サイクル図を見てみると DevOps の実践において、テストは継続的な作業であり、個々の展開の基本的な部分であることは明らかです。
DevOps の無限サイクル図
開発および提供中のテストと品質保証は、開発者が行うすべての作業の重要な部分です。 そのためには、すべてのタスクにテストを含めるように考え方を変える必要があります。
テストはすべてのチーム メンバーの日常業務の一部になります。 継続的テストへの移行は簡単ではないため、そのための準備をする必要があります。
フィードバックの欠如
DevOps の有効性は、継続的なフィードバックに依存します。 コラボレーションやコミュニケーションの余地がなければ、継続的な改善は不可能です。
振り返りミーティングを開催しない企業は、CI/CD に継続的なフィードバックの文化を導入することが難しいと感じています。 各反復の最後には振り返りミーティングが開催され、グループのメンバーは何がうまくいき、何がうまくいかなかったのかについて話し合います。 振り返りミーティングはスクラム/アジャイルの基礎ですが、DevOps にとっても不可欠です。
振り返り会議によって、フィードバックや意見を交換する習慣が身につくからです。 開始時に最も重要な瞬間の XNUMX つは、チーム全体が理解しやすく、馴染みのあるレトロ ミーティングを定期的に開催することです。
ソフトウェアの品質に関しては、チームメンバー全員がそれを維持する責任があります。 たとえば、開発者は単体テストだけでなく、テストのしやすさを念頭に置いたコードも作成できるため、最初からリスクを軽減できます。
テストに対する認識の変化を反映する簡単な方法の XNUMX つは、テスターを QA ではなくソフトウェア テスターまたは品質エンジニアと呼ぶことです。 この変更は単純すぎる、あるいは愚かに思えるかもしれません。 しかし、誰かを「ソフトウェア品質保証スペシャリスト」と呼ぶと、製品の品質に誰が責任を負うのかという誤った概念が生じます。 アジャイル、CI/CD、DevOps の実践では、全員がソフトウェアの品質に責任を負います。
もう XNUMX つの重要な点は、チーム全体とそのメンバー、組織、関係者それぞれにとって品質が何を意味するかを理解することです。
ステージクリアの誤解
品質が継続的かつ共有されたプロセスである場合、段階の完了についての共通の理解が必要です。 ステージが終わったことをどのように理解すればよいでしょうか？ Trello ボードまたは他のかんばんボードでマイルストーンが完了としてマークされるとどうなりますか?
完了したマイルストーン (DoD) の決定は、CD DevOps/CI のコンテキストにおいて強力なツールです。 これは、チームが何をどのように構築するかの品質基準をより深く理解するのに役立ちます。
開発チームは「完了」が何を意味するかを決定する必要があります。 彼らは、各段階が完了したとみなされるように、座って各段階で満たさなければならない特性のリストを作成する必要があります。
国防総省は、すべてのチームメンバーに明確であり、相互に合意されている場合、プロセスの透明性を高め、CI / CD の実装を促進します。
現実的で明確に定義された目標の欠如
これは最も頻繁に引用されるヒントの XNUMX つですが、繰り返す価値があります。 CI/CD や DevOps の実装など、重大な取り組みを成功させるには、現実的な目標を設定し、それに対するパフォーマンスを測定する必要があります。 CI/CD で何を達成しようとしていますか? より良い品質でより迅速なリリースが可能になりますか?
設定された目標は透明かつ現実的であるだけでなく、会社の現在の活動と一致している必要があります。 たとえば、顧客はどのくらいの頻度で新しいパッチやバージョンを必要としますか? ユーザーに追加のメリットがない場合は、プロセスを過負荷にする必要はなく、より迅速にリリースされます。
また、必ずしも CD と CI の両方を実装する必要はありません。 たとえば、銀行や診療所などの高度に規制された企業は、CI のみを扱う場合があります。
CI は、DevOps を導入する企業にとって良い出発点となります。 これが企業に導入されると、ソフトウェア配信へのアプローチが大きく変わります。 CI をマスターしたら、プロセス全体の改善、ロールアウト速度の向上、その他の変更を検討できるようになります。
多くの組織では XNUMX つの CI で十分であり、CD は価値を付加する場合にのみ実装する必要があります。
関連するダッシュボードと指標の欠如
目標を設定したら、開発チームは KPI を測定するためのダッシュボードを作成できます。 開発前に、監視されるパラメータを評価することは価値があります。
チーム メンバーごとに異なるレポートやアプリケーションが役立ちます。 スクラムマスターはステータスとリーチをより重視します。 一方、上級管理職はスペシャリストの燃え尽き症候群に興味があるかもしれません。
一部のチームは、赤、黄、緑のインジケーターを備えたダッシュボードを使用して CI / CD のステータスを評価し、すべてが正しく行われているかどうか、またはエラーが発生したかどうかを把握しています。 赤は、何が起こっているかに注意を払う必要があることを意味します。
ただし、ダッシュボードが標準化されていない場合、誤解を招く可能性があります。 誰もが必要とするデータを分析し、それが何を意味するのかについての標準化された説明を作成します。 グラフィック、テキスト、数字のうち、関係者にとってより意味のあるものを見つけてください。
手動テストの欠如
テストの自動化は、優れた CI/CD パイプラインの基礎を築きます。 ただし、すべての段階でテストが自動化されたからといって、手動テストを行うべきではないというわけではありません。
効率的な CI/CD パイプラインを構築するには、手動テストも必要です。 テストには人間による分析が必要な側面が常にあります。
手動テストの取り組みをパイプラインに統合することを検討する価値があります。 いくつかのテスト ケースの手動テストが完了したら、展開フェーズに進むことができます。
テストを改善しようとしないでください
効果的な CI/CD パイプラインには、テスト管理や統合、継続的なモニタリングなど、適切なツールへのアクセスが必要です。
強力で品質重視の文化を築くことは、 、展開後の顧客エクスペリエンスを監視し、改善を追跡します。
簡単に実践できる実践的なヒントをいくつか紹介します。
- テストが書きやすく、コードがリファクタリングされたときに壊れないように十分な柔軟性があることを確認してください。
- 開発チームはテスト プロセスに参加する必要があります。CI パイプライン中にテストすることが重要なユーザーの問題とリクエストのリストを参照してください。
- 完全なテストをカバーできない場合もありますが、UX とカスタマー エクスペリエンスにとって重要なフローが必ずテストされていることを確認してください。
最後になりましたが重要なポイント
CI/CD への移行は通常、ボトムアップで開始されますが、最終的には、経営陣の参加、企業の時間とリソースが必要な変革となります。 結局のところ、CI / CD はスキル、プロセス、ツール、文化の再構築のセットであり、そのような変更は体系的にのみ実装できます。
このトピックに関して他に何を読むべきか:
- .
- .
- .
出所： habr.com