DevOps の原則とベストプラクティス
より効率的なワークフローを実現する DevOps の 6 つの原則
DevOps の主なプラクティスのいくつかは、クランチ(過重労働)を減らしつつ、制作をスピードアップするのに役立ちます。自動化を適切に実装し、最も関連性の高い KPI を追跡することが、スタジオを成功に導くのにどのように役立つかをご覧ください。
クランチ(過重労働)や自己犠牲によって成り立つ労働環境を排除するには、効率性を高めればよいということだけではありません(とはいえ生産性アップにはつながりますが)。チームが躍動して最高の作品を生み出すことができる、プラスの効果をもたらす持続可能な労働文化を構築することも重要です。コラボレーションを促進する文化では、従業員が自信を持つことができ、アイデアがより広く共有され、一体感が強く、より高い説明責任が存在します。これらはすべて、生産量と収益にプラスの影響をもたらします。
お互いが協力しやすい環境を構築するには、アイデアに悪いものはないということを前面に出しつつ、風通しを良くして透明性を高め、フィードバック(プラスとマイナスの両方)を受け入れやすくします。チーム間で互いに影響を与えることができるようなシステムを導入し、個人とチームの両方の成功を公の場で認めます。バージョン管理システムなどの全員が使用できる適切なツールの存在も重要です。
DevOps において、「シフトレフト」の原則とは、ワークフローのステップを再編成することを指します。通常は開発パイプラインのずっと下流で発生するプロセスが、DevOps ライフサイクルのベストプラクティスに合わせて、より早い段階に「シフトレフト」されます。
CI/CD は、チームがアジリティを高めるうえでシフトレフトがどのように役立つかを示す一例です。継続的インテグレーション(CI)は、作業を中央のリポジトリに自動的にマージするプロセスです。変更は、ビルドを構築し、そのビルドに対して自動テストを実行することで検証されます。
継続的デプロイ(CD)は、CI の後を受けて、そのビルドからリリースをデプロイし、システムレベルの自動テストを実行します。従来、このプロセスは手動で行われていたため、パイプラインの速度低下につながっていました。CI/CD を実装することで、ソフトウェアの構築、パッケージ化、テストを一貫して自動化することができます。
DevOps のコア原則の 1 つは、時間を無駄にし、ヒューマンエラーにつながる手動でのプロセスを排除することです。テストやエラー追跡を担う自動ツールは、それらのプロセス全体をより効率的にしつつ、バグを探し出して潰すという面倒な作業からチームを解放します。実際、エラーの監視やレポートを担う適切なツールセットは、バグを逆手にとり、最適化されたコードを指し示す、ひいてはより優れた製品に仕上げるための道しるべとすることで、有効活用するのに役立ちます。
自動テストは、DevOps の「シフトレフト」の原則のもう 1 つの例です。従来のワークフローでは、ビルドのライブへのプッシュとテストは手動で行われていました。自動テストが組み込まれたワークフローでは、コードの変更がビルドにリリースされる前のほか、プロダクションに先立ってもエラーを監視できます。ライブになる前にエラーにフラグが立てられることで、プログラマーはリアルタイムでトラブルシューティングを行い、パッチや修正プログラムなどのサービスの中断を最小限に抑えることができます。
パイプラインのパフォーマンスを定量化し、最適化を行うチャンスを見つけるには、いくつかの主要業績評価指標(KPI)を追跡する必要があります。DevOps に大きく関わる 4 つの KPI は、次のとおりです。
- デプロイ頻度:コードがステージング、テスト、プロダクションにデプロイされる頻度
- 変更リードタイム:あるコミットがプロダクションに投入されるのにかかった時間
- 変更失敗率:プロダクションを停止させているデプロイの割合
- 平均修復時間(MTTR):製品またはシステムの障害が発生してから回復するまでの平均時間
その他の KPI としては、次のものがあります。
- デプロイ時間:コードをステージング、テスト、プロダクションにデプロイするまでにかかった時間
- プルリクエストサイクル時間:コードの記述とデプロイにかかった時間
- エラー数
- 平均検出時間(MTTD):エラーが発生してから検出するまでの平均時間
関連性の高い実用的な KPI に注目します。追跡する指標が多すぎると、情報過多になったり、データに脈絡がなくなったりして、最適化が困難になる場合があります。
DevOps の原則を実装するチームは、アジャイルプラクティスからメリットを享受できます。アジャイルと DevOps は互いに補完し合うもので、アジャイルの価値観は効果的な DevOps のコラボレーションの中核をなします。
DevOps は、プリプロダクションからリリースまで、プロダクションプロセス全体にわたる反復型開発に重点を置いており、更新は常に週に数回プッシュします。アジャイルはプロダクションフェーズにより重心を置いており、スプリントモデルに従って、新しいビルドが数週間または数か月ごとなど、より長期にわたる頻度でリリースされます。
DevOps を実践する人たちは、アジャイル型プロジェクト管理手法のメリットを享受できます。かんばんやスクラムなどのアジャイルプラクティスにより、ワークフローを整理された状態に保つことができます。また、主に生産性の追跡、バーンダウンチャートの計算、バックログの整理に使用されるツールを活用して、プロセスや会議にも重点を置いています。
DevOps におけるフィードバックループとは、1 つ以上のプロセスまたは結果を改善することを目的として、ある入力が出力に送信され、再び戻ってきてレビューされることを指します。
フィードバックループには 2 つの種類があります。強化型フィードバックループでは、あるプロセスに対してプラスの効果をもたらすアップデートが別の関連するプロセスにメリットをもたらし、元のアップデートの価値を高めます。「変化を加速するループ」と呼ばれることもあります。バランス型フィードバックループでは、あるプロセスに対してプラスの効果をもたらすアップデートが別のプロセスにマイナスの効果を及ぼし、元のアップデートの価値が疑問視されます。一般的に、強化型フィードバックループは最大化し、バランス型フィードバックループは最小化する必要があります。
フィードバックループの期間が短いほど、保守、監視、最適化が容易になります。
類似のリソース
ソースコード管理(SCM)は、チームが作業をスピードアップし、共同作業を効率化するのに役立ちます。使用するタイミングやしくみなど、バージョン管理ツールについて知っておくべきすべてのことについて説明します。
DevOps プラクティスを実装すると、開発パイプラインが合理化され、チームとユーザーの満足度を高めることができます。DevOps がどのように役立つかをご確認ください。
アジャイルと DevOps の目標は同じであり、定期的なリリーススケジュールを通じて顧客価値を提供することです。しかし、そのアプローチは少し異なります。これらがどのように連携するかをご覧ください。
DevOps 関連 e ブック
すべてのゲーム開発スタジオが必要とする DevOps ツールの詳細について確認し、Unity のソリューションのポートフォリオを活用して成功への道筋を見つけ出したスタジオからお話を伺います。
クラッシュやエラーの管理を担う自動化された DevOps ソリューションが、開発期間を短縮し、コストを最小限に抑え、より優れたユーザー体験を届けることにどのように寄与するかをご覧ください。
作業者自身がオーナーである協同組合型のスタジオがどのようにして制作においてアーティストとエンジニアの足並みを揃えさせているのでしょうか?KO_OP が自社の DevOps の方法論の一環として Unity Plastic SCM をどのように実装したかをご覧ください。
Unity のソース管理システムは、単にコードだけを念頭に置いて設計されているわけではありません。プログラマーにとってもアーティストにとっても使いやすい 1 つのプラットフォームで、すべてのバージョンを監視下に置いて管理しましょう。