クライアント サイトに展開されているオープン ソース ソフトウェアの一部は、ストック ソフトウェアの 99.9% であり、1 つまたは 2 つの小さなバリエーション (依存関係といくつかの構成設定の変更) があります。元のコードは Github リポジトリにあり、かなり急速に開発されています。変更を維持しながら、コードを時々再デプロイしたいと考えています (おそらく、既存のデプロイにプルするのではなく、新しいビルドとして)。また、セットアップが完了したら、更新プロセス全体をクライアントに移行する必要があります。
これを管理する最善の方法は何ですか? いくつかの可能性:
フォークしてマージ
コードを新しい github リポジトリにフォークして、メイン リポジトリからの変更を頻繁にマージすることができます。これについて私が気に入らないことがいくつかあります：
- 私たちの変更は歴史に埋もれてしまいます。
- 余分なメンテナンスが発生します (そして、Github の Web アプリを介してリポジトリに新しい変更をプルする方法はありません。誰かがデスクトップからプルしてプッシュする必要があります)。
- コードはリポジトリからデプロイされるため、特に探していない限り、元のリポジトリの新しいブランチなどの変更を見逃すことになります。ローカルでは、Git はデプロイメントが「最新」であると言うでしょう。
フォークとリベース
コードをフォークして変更を追加し、再デプロイするたびにフォークをチェックアウトして、すぐに最新のメイン バージョンにリベースできます。
気に入らない点: 1. これが実際に機能するかどうかはほとんどわかりません。以前にこれを試したときに、奇妙なマージ競合が発生したことを思い出したようです。
バリエーションをパッチとしてどこかに保存する
たぶん、フォークするべきではありません。バリエーションのパッチをどこかに保存する必要があるかもしれません。その場合、展開プロセスは次のようになります。
- 最新のメイン バージョンを確認する
- パッチをダウンロードして適用する
これを行う必要がないようにコードを改善します
理想的には、コードを改善して、すべての「バリエーション」がクリーンな構成ファイルを介して処理されるようにします。このファイルは、競合することなく、コピーするだけで済みます。
考え？これは異常な状況ですか？私が見逃している他の解決策はありますか？このボックスには root アクセス権がないため (少し面倒です)、自動展開ツール (Chef など) は使用していません。