バージョン管理が物事を処理する方法とAPIが公開される方法(つまり、Webサーバーが物事を処理する方法)を組み合わせようとしているように見えるという点で、あなたはこれを少し曇らせていると思います。
API の複数のバージョンが同時に機能するためには、コンシューマーはおそらく、特定の呼び出しに使用するバージョンを指定する必要があります。この回答では、バージョンが API URL の最初の「ディレクトリ」コンポーネントとして指定されるように、Stack Exchange API と同様の方法で作業していると仮定します (たとえば、バージョン 1.5 の場合、リクエストをhttp://domain.tld/1.5/call
、私が使用するバージョン 1.6http://domain/1.6/?method=call
など)。しかし、適切なバージョンを決定し、Web サーバー レベルで要求を正しいコントローラーにルーティングするための何らかのメカニズムがある限り、実際にはこの要素は重要ではありません。
バージョン管理
ここでのアプローチは非常に単純です。すべてのバージョンは、リポジトリ内に独自のブランチを取得します。そのバージョンに対して実行される開発作業は、バージョンのブランチからのブランチで実行されるか、バージョンに直接コミットされます。マスターには常に最新の安定版リリースが含まれます。
たとえば、現在のリリースが 1.5 で、現在すべてが master の下にあり、履歴ブランチがないとします。現在の安定コードの下に線を引き、1.5 というブランチを作成します。ここで、1.5 ブランチでビルドする 1.6 で開発を開始するには、master から新しいブランチを作成し、1.6 と呼びます。
1.6 に向けた開発は、1.6 ブランチ、または 1.6 をベースとして作成された他のブランチで行われます。これは、必要に応じてすべてが適切に 1.6 ブランチに適切にプッシュ/プルできることを意味します。
1.5 リリースで小さなバグ修正を適用する必要がある場合は、1.5 ブランチで簡単に行うことができます。1.6 ブランチからコミットをプルしたい場合は、それを「チェリー ピック」する必要があります。ブランチが分岐し始めているため、「安定版」を保護するために最大の安全性を確保するために、そのような問題は手動で処理する必要があります。 "コードベース。
1.7/2.0 などを作成するときが来たら、1.6 リリースをマスターにプルし、タグを付けて、新しいバージョン用の新しいブランチを作成します。
このようにして、バージョン/リリースごとに誰がいつ何をしたかという完全な履歴がブランチに保存されます。他の人が述べたように、マイルストーン リリースにタグを付けることを忘れないでください。
ウェブサーバー
上記のアプローチでは、Web サーバーのセットアップを維持するのはかなり簡単です。各リリースのルートは、適切なブランチと単純に同期されます。
したがって、簡単にするために、バージョン管理のリポジトリのルート ディレクトリが API コードのドキュメント ルートに対応していると仮定してみましょう (実際にはそうではないかもしれませんが、URL の書き換えまたは同様のアプローチで解決できます)。これ)。
Web サーバー上のドメインのドキュメント ルートに、次のディレクトリ構造を作成します。
<ドキュメントルート>
| |
|--- 1.5
| |
|--- 1.6
1.5、1.6 の各ディレクトリに、中央のバージョン管理からリポジトリを複製し、適切なブランチに切り替えます。変更をライブにプッシュするたびに、適切なブランチのバージョン管理から変更をプルダウンするだけです。
大規模な環境では、バージョン識別子をサブドメインとして各バージョンを提供する専用のサーバー全体を使用する場合がありますが、リポジトリを各サーバーのドキュメント ルートに直接複製できることを除いて、同じ一般原則が適用されます。
新しいブランチのディレクトリを作成し、そこにリポジトリをクローンし、適切なブランチに切り替え、リリース用のパッチ/バグ修正を取得するプロセスの多く (すべてではないにしても) は、scripts/cron などを使用して自動化できますが、これを行う前に忘れないでください: 人間の関与なしにライブ サーバーに変更をプッシュすると、多くの場合、失敗に終わります。
別のアプローチ
...ドメインのドキュメント ルートとして機能する単一の親リポジトリを作成することになります。この場合、各バージョンのリポジトリのルートにサブモジュールを作成します。これが作成する全体的な効果は非常に似ていますが、サーバー上の単一のリポジトリを同期するだけで済み、バージョン管理によって定義された Web サーバーのディレクトリ構造を維持するという「利点」があります。ただし、個人的には、いくつかの理由から、このアプローチは好きではありません。
- サブモジュールは維持するのが面倒です。それらは特定のコミットに関連付けられており、それを忘れがちです。
- ブランチ駆動型のアプローチによって提供される制御は、より詳細で、何が起こっているかについてより明確になっていると思います。
ただし、これらの理由はどちらも主に個人的な好みであることを認めているため、可能性として取り上げています.