外部アーティファクトのメンテナンスモデル
ソフトウェアソリューションを全体的に維持することを考えるとき、実際のソースコードに加えて、コード以外の変更制御や構成管理などについて考える必要があります。たとえば、大規模なWebアプリケーションを維持するために、以下をトレースします。
「この特定のxx.yy.zzバージョンのソリューションパッケージを展開する一環として、ファームに対して次の（手動の）構成変更を行います。」
私はこれに対してかなり良いモデルを実装しましたが、今、次に大きな問題に取り組んでいます-私たちが所有していない他のシステムの変更をどのように管理するのですか？簡単な例を見てみましょう。
ソリューションチームが所有するASP.NETアプリケーションがあります（PLMチームと呼びましょう）。次のリリースには、SAPチーム（別のメンテナンス傘下にある）がBAPIエンドポイントの1つにも変更を展開する必要がある変更が含まれています。
もちろん、リリース時の展開の実際の調整は、単純な人間の相互作用と調整ですが、SDLC全体の観点からは次のようになります。
- この例の「PLMチーム」は、この依存関係をアーティファクトとしてパッケージ化し、今後の変更として、また展開後、所有する要件はあるが直接制御しない実装を持つ管理された依存関係としてどのように追跡しますか？
- それについてキャプチャするための正しい情報は何ですか？彼らが管理している非コード構成アイテムとはどのように異なって扱われるべきですか？
2つのチームが絶えずコミュニケーションをとる場合、それはビジネスプロセスではなく、人間の相互作用と調整に関するものです。両方のプロジェクトで使用されるインターフェースがどのように変更されるかについて同意し、変更を実装し、両方の製品を同時にデプロイします。同時に、マシンをファームから切断し、両方のアプリを停止してから、両方のアプリに更新を適用すると、アプリが再び実行を開始し、マシンをファームに戻すことができます。
2つのチームがうまくコミュニケーションできない場合（地理的に異なる都市にあるか、お互いを嫌っているなどの理由で）、ビジネスプロセスの観点から両方のアプリケーションを同時に更新するためにできることは実際にはありません。
この2番目のケースでは、新しいバージョンのAPIをリリースした大規模なAPIプロバイダーの役割を担っていますが、古いバージョンをまだ使用している顧客がたくさんいます。次のバージョンが最初のバージョンを拡張しない¹が、それを変更する場合²は、両方のバージョンを実行し続ける必要があります。
これは、次の両方があることを意味します。
http://api.example.com/products/get/5
そして：
http://api.example.com/v2/d6w9UbnZ50/products/get/5
↑ ↑
version token
また、新しいクライアントは2番目のバージョンを使用することでRESTfull APIの恩恵を受けることができますが、セッションに依存する古いクライアントは引き続きAPIを使用できます。
あなたのプロジェクトは他の1つのプロジェクトによってのみ使用されているため、developingとmaintaining同じプロジェクトの2つのバージョンは法外な費用がかかります。つまり、2番目のバージョンが開発およびテストされたら、できることは何でも試す必要があります他のチームにできるだけ早く2番目のバージョンの使用を開始するように強制します。これは、最初のバージョンにバグがあることを伝えるチケットを開いた場合、最初のバージョンが維持されなくなったことに注意して、このチケットを「解決しない」としてすぐに閉じる必要があることも意味します。
¹拡張：既存のメソッドにオプションの引数を追加したり、オーバーロードや新しいメソッドを追加したりしても、現在のAPIは壊れません。
²変更：メソッドの名前を変更してより明示的にするか、引数を削除するか、必須の引数を追加すると、現在のAPIが破損します。