WordPressプラグインのリポジトリ管理を最適化する

CustomDataBaseTables Version2のプラグインを公開するにあたって、ついでに今後の運用がしやすいようにリポジトリの管理フローを自分なりに最適化してみようと思った次第。

ちなみに、現状のリポジトリ管理状況は下記のようになっている。

リポジトリ GitHub WordPress.org(SVN) 備考
公開用 (master) Revision: 1254821 最新バージョンのリポジトリ(原則的にGitHubとSVNの両リポジトリのソースは同一)
ソース管理用 master ソース管理用のリポジトリ
開発用 version_2 開発用のリポジトリ(バージョン2開発専用)

今回、GitHub側のversion_2リポジトリをmasterにmergeしてしまうのだが、プラグイン・バージョン2は動作環境がPHP5.4以上であるため、一応、PHP5.3以前の環境向けのユーザー用の開発継続用にバージョン1系のリポジトリも残しておきたいと思う。
なお、SVN側はあくまでもリリース専用リポジトリという位置づけにして、GitHubのmasterとの同期はしないことにする。

──ということで、理想のリポジトリ管理仕様は下記のようになるのかな…。

リポジトリ GitHub WordPress.org(SVN) 備考
公開用 (master) Revision: 1254821 最新バージョンのリポジトリ(原則的にGitHubとSVNの両リポジトリのソースは同一)
ソース管理用 master ソース管理用のリポジトリ
バージョン1系開発用 legacy-master バージョン1系開発専用(masterへのマージは禁止)
最新開発用 develop 最新バージョンの開発用

このリポジトリ構成を実現するには、

  1. version_2リポジトリをmergeする前に、masterブランチからlegacy-masterブランチを切る(GitHub側)
  2. version_2ブランチをmasterにmergeする(GitHub側)
  3. masterブランチからdevelopブランチを作成する(GitHub側)
  4. GitHubからmasterブランチをローカルリポジトリにcloneして、ディストリビューション・ソースのみをsvnへcommitする

毎回 4. の対応が面倒だが、公開環境側にはnpm、gulp、bower系のリソースや、gitの履歴情報は必要ないので、ここで削ぎ落として最適化しておかないと無駄にダウンロードファイルが肥大化してしまう。

では、自分自身の備忘録的に手順をまとめておこうかと。

1. version_2リポジトリをmergeする前に、masterブランチからlegacy_masterブランチを切る

最初にmasterブランチに移動して、legacy-masterブランチを作成する(ローカルリポジトリにて)。

次に、ブランチをコミットしてリモートへpushする。

GitHubサイトにて、legacy-masterブランチが追加されていることを確認する。

2. version_2ブランチをmasterにmergeする

masterブランチに移動して、version_2ブランチのmergeを実行する(ローカルリポジトリにて)。

merge後に、リモートリポジトリへローカルのmasterをpushする。

これでリモートのmasterリポジトリもバージョン2の最新ソースとなった。この時点でversion_2リポジトリは不要になったので削除する(ローカルリポジトリにて)。

3. masterブランチからdevelopブランチを作成する

これは、masterブランチに移動してから、developブランチを作成するだけだ。

4. GitHubからmasterブランチをローカルリポジトリにcloneして、ディストリビューション・ソースのみをsvnへcommitする

ここからが面倒なところだ。まず、プラグインリリース用のディストリビューション・ソースをデプロイする必要があるため、npmがグローバルインストールされている環境下にmasterブランチをcloneする(cloneしたmasterブランチに改めてnpmのグローバルインストールから始めてもイイ…というか正規の流れはこちらなのだが、npmのインストールには結構時間がかかるので、せめてローカルインストールからデプロイ環境構築をした方が圧倒的に早い)。

まず、デプロイ環境下にて適当にディレクトリを作成して、そこにmasterブランチをcloneし、npmをインストール、bower、gulpを実行する。

これで、ディストリビューション・ソースがデプロイされるので、プラグインのリリースに必要なアセットのみを抽出して、SVNのローカルリポジトリへコピーする。私の場合、この操作はローカルPC(Windowsマシン)上で行うので、コマンドライン操作は特にない。
コピーが完了したら、リモートブランチをtrunkに切り替えてから、適宜ファイルやディレクトリの追加・削除を行って、SVNコミットという流れになる。

この運用部分が毎度重いので、なんとか改善したいものだが…まぁ、今はおいておこう。

Leave a Reply

Your email address will not be published.