コードを再利用可能なビットに分割した後、どのようにテストしてデプロイしますか？

私たちは1人の開発者と、すべてのコードを含む1つのsvnリポジトリから始めました。

^/foo/trunk/module-a
^/foo/trunk/module-b
^/foo/trunk/module-b/submodule-b1
^/foo/trunk/website1

（当時、これは大きな改善でした）。これが少し成長する機会を得た後、循環依存、テストスイートの遅延、コードの再利用に関する一般的な問題が発生し始めました（たとえば、website1の機能セットが他の汎用モジュールaに侵入したため）。

コードベースをモジュール化して、まもなくgitに移動することを期待して（そしてgitがsvn mega-reposを好きではないところを読んだことを期待して）、もっと細かい構造に移行しました：

^/module-a/trunk/
^/module-b/trunk/
^/module-b/trunk/sumbmodule-b1
^/earlier-sub-sub-sub-module-c/trunk
etc. (about 120 such modules)

これは概念的に素晴らしかった。モジュール化されたコードの増加、テストスイートの高速化、ドキュメント化の容易化など。より一般的なコンポーネントの一部をオープンソース化し、すべてのモジュールをpipインストールpip install -e .可能にしました（developmentvirtualenv にインストールするために使用）。

^/srv/trunkランタイム環境のフォルダ構造を含むリポジトリを作成しました。^/srv/trunk/libモジュール、/srv/trunk/src残りの部分^/foo/trunk、^/srv/trunk/wwwウェブサイトなど

そして最後に（非常に長い時間前に使用したperforceからのアイデア（[ https://www.perforce.com/perforce/r12.1/manuals/cmdref/client.html]））を作成し、「vcs-関連するすべてのリポジトリと、それらを開発環境にチェックアウトする場所と、それに対応するコマンドをリストしたテキストファイル。たとえば、vcs-fetc行：

svn srv/lib/module-a ^/module-a/trunk

いずれかを引き起こします（初回）

cd /srv/lib && svn co ^/module-a/trunk module-a

または（後で）

cd /srv/lib/module-a && svn up

そして同様にgithub repos（私たち自身と変更された/変更されていないベンダーパッケージの両方）についても同様です。

本番環境の作成には同じvcs-fetchプロセスを使用しましたが、vcs-fetchを実行した後、prodで実行されていたバージョンを知る方法がないことはすぐにわかります。

mega-repoを使用すると、トランクから製品を更新する前にリビジョン番号をメモするだけで済み、戻るのは簡単でしたsvn -r nnn up .。svnとgitの両方のコード（およびhgの1つのモジュール）と〜120リポジトリでは、これを行う方法は明らかではありません。

私は今日http://12factor.net/を読みました、そして最初の要素は「One codebase」なので、私はここで正しい道を離れているのかどうかも疑問に思っていますか？

私が持っていた1つのアイデアは、pipでインストール可能な「展開」ホイールを作成し、それらをrequirements.txtファイルに「バンドル」する展開スクリプトを作成することでした。デプロイでは、新しいvirtualenvを作成し、デプロイホイールをリストしたrequirements.txtファイルをpipインストールして、アクティブなvirtualenvを切り替えます。以前の状態に戻すには、virtualenvを元に戻すだけです（ただし、virtualenvを永久に保持したいと思わない限り、特定の時点に戻ることはできません-私の経験では必要ありませんでした）。

この時点で、間違った方向に歩いているのか、それとも正しい道を十分に歩いていなかったのかと思います。（私が読んでいるすべてのものが「あなたのアプリ」について話し続けており、それがどのように同じコードベースから14のWebサイトを実行することになるのかわかりません...）

ブランチ（または「タグ」または「リリース」ブランチ）がないようです。

SVN revnumをリファレンスとして使用して、インストールするバージョンを判別する代わりに、そのリリースされたリビジョンにブランチを作成する必要があります。次に、そのブランチ名をデプロイします。

変更がない場合でも分岐が容易になるため、すべてのモジュールが同じリリース番号を保持しますが、OSSパッケージは変更なしで分岐することを好まない可能性があるため、次善の策は依存関係のスクリプトを保持することです-バージョン5製品のOSSモジュールX v2などが必要です。

バージョンの参照を停止し、代わりにブランチ名を操作するようにスクリプトを変更します（それらは何でもかまいませんが、Release_1_2_3などの固定の命名規則を決定するのが最善です）

別のヒントは、現在のバージョンを説明する各モジュールを含むファイルを維持することです。必要に応じてこれらを自動生成できます。また、完全な変更ログも含めることができますが、誰もが見ているだけでどのバージョンがデプロイされているかを確認できます。

あなたはすでに多くの良いアイデアを持っていると思います。私は長年にわたってそれらのほとんどをさまざまなプロジェクトで使用してきました。あなたの主な関心事は、分割した場合、特定のパッケージに含まれるすべてのモジュールのバージョンを特定できないことです。それらを。

@ Ext3hが言及しているように、特に複数のチームがあり、リリースサイクルが異なる場合は、ある程度の細かさでそれらを分割するのがすべてです。

モジュールがどの程度分離されているのか、またはバージョン管理をどの程度詳細にしたいのかわからないため、いくつかのオプションを提案します。

gitサブモジュールを使用します。サブモジュールを使用すると、svnのセットアップと同様に、各モジュールを別々のgitリポジトリに保存でき、また、考えていることにも対応できます。次に、それらのモジュールをルートプロジェクトにリンクします。ルートプロジェクトには、独自のコミットごとに、各サブモジュールの関連するコミットへの参照が含まれます。

IMOこれは理論的には優れたセットアップであり、かなりシンプルです。主な欠点は、サブモジュールのワークフローが少し厄介であることですが、そのようなことは以前にスクリプトでうまく解決したようで、実際の問題ではないかもしれません。

もう1つの注意点は、サブモジュールのコミット参照はSHA1になるだけであり、どのブランチであるかについて人間が読み取れる詳細は決してないため、サブモジュールで直接作業したい場合は、正しいブランチを手動でチェックアウトする必要がある場合があります。

ただし、私はこのパターンを広範囲に使用していないため、あなたのような大規模なプロジェクトでどれほどの問題が発生するかはわかりません。

別の選択肢は、ある種の依存関係マネージャーを使用することです。これには、各モジュールまたはモジュールのセットを個別にバージョン管理、パッケージ化、および公開できること、および必要なときに必要な方法でそれらのパッケージをまとめることができるシステムがあることが必要です。

あなたはすでにpipを提案しており、提案から欠落しているように見えるのは、ビルドと一緒に、またはルートプロジェクトリポジトリに結果のrequirements.txtを保存することです。これにより、保存せずに後でvirtualenvを再作成できます。ディスク上で。

他のシステムもあります。私は、Apache Ivyのわずかにカスタマイズされたバージョンを使用してかなり大きなプロジェクトをセットアップし、各モジュールをパッケージ化して公開するためのツールと、最終的なプロジェクトのためにそれらを一緒にプルするためのツールとして使用しました。Ivyは、後でセットアップを再作成する必要がある場合に、参照しているすべてのモジュールのすべてのバージョンをリストしたマニフェストも保存します。