先月のContinuous Lifecycle Londonにて、Electric Cloudでプロダクトマネージャを務めるAvantika Mathur氏が継続的デリバリーパイプラインにおけるスクリプトの増加にまつわるコストについて語った。メンテナンスコストに加えて、もうひとつ大きなコストは、本番環境に変更をデプロイするまでに実際に何が実行されるのか、その可視性と監査可能性が欠けていることだ。多くの組織がこのことに気づいていない。
この問題を解決するには、まず問題を認識し、パイプラインオーケストレーションに対する指針を立案する必要がある。Mathur氏は出発点として、以下の原則を推奨する。
- デプロイ間の反復可能性と一貫性を保証する
- アプリケーション定義をデプロイ/実行される環境から分離する
- 環境間のポータビリティを目指す
- 特定のツールや技術へのロックインを避ける（別の言葉で言うと、プラクティスはツールではなく作業の指針となるようにする）
スクリプトを膨張させないために、Mathur氏は次のアプローチを提案する。まずスクリプトをパラメータ化した共通関数にリファクタリングし、それから可能なら、同じ作業ができる、あるいはもっとうまくできるツールで置き換えるのだ。
しかし、大量のスクリプトに一度に取り組むのはチャレンジング（技術と人の両方の観点から）かつ非効率（最初に低いROIにフォーカス）だ。Mathur氏はイテレーティブなアプローチをすすめている。まず、バリューストリームマッピングを行い、デリバリーを遅くしている、あるいはデリバリープロセスをわかりにくくしている、直接のボトルネックと依存関係を特定する。これは、どのスクリプトを最初にリファクタリングする必要があるか、優先順位を付けるのに役立つだろう。また彼は、重複したタスクを特定するために、既存のスクリプトを分類（設定、デプロイ、テスト自動化など）すること、見積もりの複雑さの観点から分類すること、潜在的メリットを見積もるためにスクリプトの実行頻度を測定すること、最終的に、コストを最小限にするためにベターな（自家製でない）代替案がないか調べること、などをすすめている。
Mathur氏は、こうした「スクリプトの悪夢」の直接の影響を目の当たりにしてきたという。チームが（発展ではなく）保守にエンジニアリング時間の80%を費やすこと、より高速により安全にデリバリーするためでなく、非効率で遅いプロセスをただ自動化するためのスクリプトなどだ。スクリプトが制御不能になっていることや、パイプラインオーケストレーションのケアが不十分なことを示す典型的な「におい」には、「スクリプトの保守に専念するエンジニア」、「脆いスクリプトを変更することに対する恐れ」、「実行されることの可視性の欠如」、「監査準備に時間がかかるプロセス」などがある。
まとめると、Mathur氏は「パイプラインをプロダクトとして扱い」、パイプラインに対する各変更は「本番投入」（すなわち、エンジニア全員に使えるようにする）前にテストして完全に検査済みにすることをすすめている。これはまた、パイプラインを全員に見えるようにすること、メトリクスとベンチマークによりパフォーマンスを測定し改善すること、できるだけ既存のものを再利用すること、を意味している。
Rate this Article
- Editor Review
- Chief Editor Action