前回の投稿では、SAP IT チームが DevOps アプローチを完全に実装する過程で取り組む必要のあるコンポーネント領域と成功の原則について説明しました。この投稿では、最初の 2 つについて詳しく説明します。
プロセスの成熟
DevOps アプローチを進めるには、変更管理プロセスが堅牢で、開発、QA、テスト、ビジネス、機能の各チームなど関係者全員が明確に理解できるものでなければなりません。変更にはさまざまな種類があり、変更はさまざまな方法で処理されます。これはロケット科学ではありませんが、この比較的単純な概念にまだ苦労しているチームがいかに多いかは驚くべきことです。「万能」な単一のプロセスで変更を管理することは、DevOps / アジャイル環境では機能しません。
DevOps / アジャイル環境でも、開発される変更にはさまざまなリスクが伴います。変更を可能な限り加速するには、プロセスがリスクの変動を反映し、それに応じて変化します。また、チームが月曜日の朝にアジャイル開発チームとして目覚める可能性は非常に低いです。したがって、少なくともしばらくの間は、従来の方法論とアジャイル方法論を含むプロセスの組み合わせが共存する必要があります。
しかし最終的には、DevOps チームはプロセスを定着させ、アプローチが成熟するにつれて改善および修正する方法を確立することになります。
プロセス自動化
それでは、SAP IT チームはさまざまなプロセスをどのように管理するのでしょうか。たとえば、どのプロセスがいつ呼び出され、誰が決定するのでしょうか。複数のプロセスが混乱することなくどのように管理されるのでしょうか。また、変更に対して適切なプロセスが実行されたことをどのようにして確認できるのでしょうか。
答えは自動化です。
ただし、自動化が効果を発揮するには、理想的には、その機能セット内でさまざまな自動化機能を提供できる必要があります。例:
- 進行中の並行開発の可視性
- 追い越しと上書きの防止
- オブジェクトタイプまたは分析されたリスクに基づく変更プロセスの割り当て
- リリース間およびリリース内の依存関係管理
- N +1変更処理の簡素化のための機能
- 承認された変更の展開
- 複数のチームにまたがるコミュニケーションワークフロー
- プロセスの実施
次のステップ
成熟したプロセスとプロセスの自動化により、完全に実装された環境を構築するための共同作業と自動化された環境が確保されます。 SAP デベロップメント アプローチ。次の投稿では、マルチトラック開発ストリームの役割と、追加コンポーネントとしてのリリース管理の価値について説明します。
