フロントエンドエキスパートチームのlacolacoです。今回はClassiの中で運用しているGitHubのテンプレートリポジトリについて、その運用方法を紹介します。これが最善である自信はないですが、一例として誰かの参考になれば幸いです！
テンプレートリポジトリ機能とは？
テンプレートリポジトリは通常のリポジトリと同様にcloneやpull、pushなどできるGitリポジトリとして機能します。テンプレートリポジトリが通常のリポジトリと違うのは、新しいリポジトリを「テンプレートから作成」できる点です。 テンプレートからリポジトリを作成することは、リポジトリをフォークすることに似ていますが、以下の点で異なります。（ドキュメントより引用）
- 新しいフォークは、親リポジトリのコミット履歴すべてを含んでいますが、テンプレートから作成されたリポジトリには、最初は 1 つのコミットしかありません。
- フォークへのコミットはコントリビューショングラフに表示されませんが、テンプレートから作成されたリポジトリへのコミットはコントリビューショングラフに表示されます。
- フォークは、既存のプロジェクトにコードをコントリビュートするための一時的な方法となります。テンプレートからリポジトリを作成することは、新しいプロジェクトを素早く始める方法です。
Classiにおけるテンプレートリポジトリ
テンプレートリポジトリは似たプロジェクトを何度も作成するときの雛形を管理する方法としてとても適しています。その一例として、Classiのフロントエンドエキスパートチームでは、AngularJSからAngularへの段階的移行を支援するテンプレートリポジトリを作成しています。
Classiのコードベースは機能やデプロイ単位に基づいていくつかのリポジトリに分割されています。そのため、ひとつの大きな移行ではなく、いくつもの段階的移行が並行して進行することになります。
AngularJSからAngularへの段階的移行では、AngularコンポーネントをCustom Elementsに変換して、それをAngularJSを利用している旧実装のHTML中に埋め込んで置き換えていくという手法を取っています。Angularコンポーネントは単にCustom Elementsにするためだけのソースコードではなく、移行の最終段階ではそのままAngularアプリケーションとして根本から置き換え可能である状態を作っていきます。
つまり、ひとつのプロジェクトの中でAngularのソースコードを通常のアプリケーションとしてデプロイできるビルド設定と、Custom Elementsのパッケージとしてデプロイできるビルド設定の共存が必要になります。毎回それぞれのプロジェクトにリポジトリの作り方をレクチャーしていくのは骨が折れますし、設定を改善したときにそれを全体に伝えるのも共通の土台がないため難しいです。
テンプレートリポジトリを運用することで、どのプロジェクトも同じスタートラインになっており、設定の改善も同じ変更を適用できることをある程度保証できるようになりました。また、実際にプロジェクトを進めていく中での発見をテンプレート側へ還元するループも生まれやすくなりました。
継続的な運用のための変更履歴
このようなテンプレート的存在は時間の経過につれメンテナンスがされなくなったり、テンプレートから新しく作成した時点からいままでの差分がわからないということになりがちです。この問題を緩和するために、テンプレートリポジトリの変更履歴を文書化しています。
具体的には、テンプレートリポジトリ内ではConventional Commits のルールに従うことで、 standard-version CLIを使ってCHANGELOG.md を自動生成できるようにしています。キリのいいタイミングでテンプレートのバージョンを更新することで、「テンプレートを更新したので各チームで変更点の追従お願いします」というコミュニケーションが容易になります。
コミットログだけではノイズが多いため、Conventional Commitsによってfeatとfixの差分がまとめられることで本当に重要な変更だけを伝えやすくなっています。
今後の課題
現状どうしても人力に頼っているのは、テンプレートのバージョンアップを派生先のリポジトリ達に伝えに行くところです。ここは何かしらの方法を使って自動化できないかと考えているところです。たとえばGitHub APIでそのテンプレートから作られたリポジトリを走査してIssueを作成にしにいくなどできるかもしれません。 また、変更の追従自体もテンプレート側のDiffをなぞって真似することになるため、マイグレーションパッチを適用するだけで済むようになれば楽になるかもしれないと考えていますが、テンプレートからの作成後に加えられた変更でパッチの互換性がなくなってしまうケースも考えると一筋縄ではいかないですね。
とはいえ、変更履歴とバージョニングを自動化するだけでもテンプレートリポジトリの運用がやりやすくなりました。読者の中でテンプレートリポジトリを運用している方の参考になれば幸いです。
