2
2
テーマ、知りたいこと
Gitリポジトリで、プログラム一式の雛形管理用プロジェクトを作成しています。
これをコードをコピー(clone)し、要件に合わせたシステム用のプロジェクトを開発しようとしています。
その際の一般的、もしくはベストプラクティスな方法は何なのかお聞きしたいです。
背景、状況
社内でプロジェクトの雛形を作り、誰でも同じ構成でシステムが構築できるように考えています。
雛形プロジェクトも各システムのプロジェクトも、Git上でコードを管理します。
雛形プロジェクトの更新は、できるだけ各システムプロジェクトへ反映させたいです。(システムによるので、反映するしないは選択したい)
当初考えた方法は、『雛形プロジェクトをshallow cloneしてリモートリポジトリを変更しpush、変更があれば雛形プロジェクトのリモートリポジトリ参照を追加しチェリーピック』でした。
※雛形プロジェクトをcloneした時点の最新のコミットログだけ欲しいため、shallow cloneしています。
それとは別に、forkしても似たようなことはできると思っています。
ただ、本来の用途とは違うと思っていて、雛形プロジェクトを改変した雛形プロジェクトを作りたい場合に使用するかなと思っています。
皆さんの考えをお聞かせください。
[06/20追記]
今回のプログラムはNode.js環境になります。
[06/20最終更新]
■その他いただいた案
・npmへ公開する(@sk_さんのComposer案より)
回答10件
#1
総合スコア92
投稿2024/06/19 15:09
一般的な方法としてはライブラリ化になると思います。
GitHubに公開したものを、例えばPHPであればComposerに公開し、ライブラリとしてインストールするように作るのが一般的な流れではないでしょうか。
ライブラリ化せず、プロジェクト自体をcloneする方法では、雛形プロジェクトの更新に懸念が残ります。
長く使う想定でしたら雛形プロジェクトの機能強化等とは別に、言語のバージョンアップに伴う雛形プロジェクトの修正なども行われると思います。それらの変更を作成済みの各プロジェクトへ反映したい場合に管理が困難ですし、
言語バージョンの古い環境へ新規にプロジェクトを設置する際にも、雛形プロジェクトの記法が新しすぎる等問題が起こります。
ライブラリ化も大変ではありますが、forkやcloneで流用できるのは限られた条件下になりそうです。
#2
@sk_さん
ご回答ありがとうございます。
質問に記載するのを完全に忘れていたのですが、今回だとNode.js環境になるため、npmに公開するということですね。
一度検討したのですが、労力という部分から検討したこと自体をすっかり失念していました。
仰っていただいたように、各プロジェクト側でどれだけ追従(反映)できるかというのが難しい部分でした。
小手先ではなく、根本的に解決できる方法の採用も検討したいと思います。
#3
総合スコア617
投稿2024/06/20 10:52
そもそも具体的にはどのようなプロジェクト雛形なんでしょうか？
同じ構成でシステムが構築できるように
これはつまりプロジェクトの形態ごとに必要なフレームワークやライブラリ、それに合わせたフォルダ構成や必須の設定ファイルetc……をまとめたようなモノ等に思われます。
こういった雛形であれば、頻出の共通機能をライブラリ化したモノのようにパッケージとして共有化して更新をまとめて反映……みたいな話にはならないような気がします。
（仮に上記のような雛形だとして）そういった雛形をリモートとして参照しといて各プロジェクトが継続的に更新を取り込むかどうか……はやったことがないのですみませんが何もアドバイスできません。
ただ、既に稼働しているシステムであれば構成を変更するような更新を取り込むことはあまりないですし、リリース前だとしてもある程度開発が進めば進むほど変更コストは上がっていきますし、時間が経つごとに雛形から乖離していくことは仕方ないものと感じます。
一般的にこういう雛形のメリットといえば、初期作業の簡易化・品質の担保だと思います。
もちろん同一構成を強制させられることもメリット（というか担保される品質のうちの一つ）ではあるのですが、それはあくまで開始（複製）時点だけであって
継続的に雛形更新による構成変更を強制したり保障したりできるようなものではないでしょう。
まあ構成変更がプロジェクトの既存コードに影響を及ぼさないor変更に既存コードを追随させられると断言できる場合に、手動で変更を取り込むかcherry-pickするか、でいうと……楽といえば楽かもしれません（コンフリクト解消がなければ）。
雛形的なものの作成といえば、生成コマンドを用意しているような言語もありますが
個人やチームレベルでならgitで管理/開始時にshallow cloneは妥当かなーと私も思います。
#4
@pecmmさん(#3)
ご回答ありがとうございます。
今回はWebフロントエンドのフレームワーク、ライブラリ、フォルダ構成、横断的コンポーネント、ルーティングなどが記載されたサンプルコード、CI設定などを含めたプロジェクト雛形を作成しようとしていました。
一番変更としてありそうなのは横断的コンポーネントの拡充ですが、稀に脆弱性対応などでNodeバージョンやライブラリのバージョン変更等も発生する想定です。
※基本的なアーキテクチャや構成を変える予定は今のところ考えていませんでした。
一般的にこういう雛形のメリットといえば、初期作業の簡易化・品質の担保だと思います。
もちろん同一構成を強制させられることもメリット（というか担保される品質のうちの一つ）
まさしくそれを狙っていました。
社内の多数のシステムがEdgeに対応しておらずIEモードでしのいでいる状況ですが、IEモード終了までに経験の浅いメンバーにも担当してもらいながらリプレイスを予定しています。
そういう意味で、雛形兼サンプルを作成し効率化や同一アーキテクチャによる保守性を狙っていました。
もしかすると、横断的コンポーネントをGitのパッケージレジストリに公開して、各プロジェクトはサンプルをコピーして公開されたパッケージをインストールするようなやり方が良いのかもしれません。
※メインの更新は、恐らく横断的コンポーネントになってくると思われるため。
#5
総合スコア7819
投稿2024/06/21 04:37
GitHubをご利用であればテンプレートリポジトリの機能を使うのが良いかと思います。
新規リポジトリの作成時にコミットの切り捨て、必要なブランチだけ複製など、シャロークローンと同様のことをGitHub側でやってくれます。
更新を任意に共有することに関しては、共有したいディレクトリをサブモジュールにするのが簡単かと思います。
#6
総合スコア21177
投稿2024/06/21 04:54
編集2024/06/21 05:20各プロジェクトへシームレスに反映
これがGitだと大変なんよなぁ
やはりフレームワーク、ライブラリ化は避けられないでしょう。
今回だとNode.js環境になるため、npmに公開するということですね。
npm(cli) は、普通にインストールすると npm(website) に問い合わせる為、
一見 npm(website) への登録が必要そうだと感じると思いますが、実は他の媒体でも大丈夫。
以下は npm install される前提のライブラリをGitHub上に保存して、
GitHubのURLを叩いて導入する例です。
bash
1$ npm install https://github.com/miyabisun/next-livescript
このように一生更新されないマイナーライブラリを
フォーク→手直し→GitHubに反映→プロジェクトルートのURLを指定
この手順でGitHub上にあるプロジェクトをnpmのライブラリとして認識させて使っています。
npm(cli) で npm(website) 以外のものを導入するときの参考サイトです。
Githubまたはローカルのnpm のパッケージをinstallする方法 | Qiita
実はGitHub相手にはSSHでのログインにも対応しているので、
機密情報が入っているプライベートに設定したリポジトリもいけます。
私が表題に関して取り組むのであれば、オレオレフレームワークとして開発しておき
そのGitHubのプロジェクトにあるREADME.mdに
「このフレームワーク使って開発するならば、こういうディレクトリ構造でこういう名前のファイルでやれよ」みたいなルールをつらつら書く感じにしますかね。
Node.jsというかJavaScriptがLISPライクの自由なルールの言語なので
どうせある程度以上はフリーダムになってしまいますからね。
あくまでお願いくらいまでしかできず、そこから先は個々の裁量や良識の問題になりますからね。
#7
総合スコア92
投稿2024/06/21 08:42
編集2024/06/21 08:44私が表題に関して取り組むのであれば、オレオレフレームワークとして開発しておき
そのGitHubのプロジェクトにあるREADME.mdに
「このフレームワーク使って開発するならば、こういうディレクトリ構造でこういう名前のファイルでやれよ」みたいなルールをつらつら書く感じにしますかね。
こちらの案が素敵だと思うんですが、こちらの形が可能であれば、加えて簡単なコマンドを作るのも良いかもしれません。
miyabi-sunさんの案で言うREADMEの代わりにコマンドやバッチを作るイメージです。
今となっては賢い方法ではないかも知れませんが、昔、初学者の部下が同時に3名ほど入社してきた時には、(環境を合わせるために、)環境構築のバッチを作りました。
例えばこんな感じです。
bash
1# 標準入力や引数で必要な情報をもらう 2 3# 中略 $DB_NAMEや$PROJECT_NAMEなど標準入力から取り、DBや設置ディレクトリを作る。 4 5# ライブラリをインストール 6composer require laravel... 7 8# パーミッションやconfig値の設定（Laravelフレームワークの設定値をいじる操作です） 9# 書き込み可能なディレクトリ 10chmod -R 0755 ${PROJECT_PATH}/storage 11chmod -R 0755 ${PROJECT_PATH}/bootstrap/cache 12# タイムゾーンやDB情報の設定 13gsed -i "s|'timezone' => 'UTC',|'timezone' => 'Asia/Tokyo',|" config/app.php 14gsed -i "s|'locale' => '.*',|'locale' => 'ja',|" config/app.php 15gsed -i "s|DB_DATABASE=.*|DB_DATABASE=$DB_NAME|" .env 16gsed -i "s|DB_USERNAME=.*|DB_USERNAME=$DB_USER|" .env 17 18# その他追加で必要なパッケージ・自社パッケージのインストール 19composer require hoge/hoge 20php artisan hoge:template # 後述、ライブラリAに定義した雛形作成コマンド 21 22# 必要なディレクトリの作成、パーミッション設定、ファイルの作成（READMEに書くべき注意事項を、代わりに実行してしまう） 23mkdir ....
私の場合は、LaravelというPHPフレームワークでの開発が主でした。
Laravelにはアルチザンコマンドという、Laravelプロジェクトルートでコマンドを実行することで規定のファイル(MVCアーキテクチャで必要なファイルなど)を作成したり、キャッシュを削除したりと様々なコマンドがあり、さらにコマンドは自身で拡張できる仕様でした。
そこで
- Laravelフレームワークに依存する自社用ライブラリAを開発し、
- 拡張アルチザンコマンドをライブラリAに定義、
- フレームワークのインストール後にライブラリAもインストール
- ライブラリAに定義したコマンドを実行する
とすることで、ここで言う必要なディレクトリ・ファイル雛形の作成等を行っていました。
また、3～4はプロジェクトごとに実施しますが、すべてのプロジェクトで実施するため、上記のバッチコマンドを用意しました。
私の説明が冗長なので大変に聞こえるかもしれませんが、土台は1週間もかからず用意できた記憶があります。
その後、バッチの内容を同期するためクラウドに置いたり、ライブラリAの強化は長期間かけて行いましたが、
結果として何かインシデントが起こった際には、対策をライブラリAに追記して次回以降同じ問題を防ぐことにも役立ち、始末書の改善策の欄は書きやすかったです(笑)
もしかすると、横断的コンポーネントをGitのパッケージレジストリに公開して、各プロジェクトはサンプルをコピーして公開されたパッケージをインストールするようなやり方が良いのかもしれません。
こちらが、私の例でいうライブラリAにあたるかと思います。
#8
@KazuhiroHatanoさん (#5)
ご回答ありがとうございます。
こちらも記載が漏れていたのですが、今回の環境ではオンプレミスで構築されているGitLabでした。
申し訳ありません。
しかしGitLabに、完全に同じ機能ではないものの類似した機能として、プロジェクトテンプレートがあるようでした。
※こちらはcloneしてpushするような形で、求める機能には達してはいなかったのですが。。。
※GitHubは便利ですね、まさしくやりたいことが一発でできて。。。会社の謎なセキュリティポリシーがなければGitHubで管理できるのに。。。
更新を任意に共有することに関しては、共有したいディレクトリをサブモジュールにするのが簡単かと思います。
なるほど、そのような考えでやれば良いのですね。
今回だと横断的コンポーネントの、コンポーネント本体とStoryBookが対象になってきそうです。
#9
@miyabi-sunさん (#6)
ご回答ありがとうございます。
このように一生更新されないマイナーライブラリを
フォーク→手直し→GitHubに反映→プロジェクトルートのURLを指定
このようなやり方でも、パッケージとしてインストールできるのですね、初めて知りました！
たしかに、node_modulesにも同じようにインストールされていますしね。
構築済みのオンプレミスGitLabでパッケージレジストリを検証していて、なぜかパッケージレジストリに公開できない現象が発生していたので、回避策としてこのような方法も検討したいと思います。(--dry-runでは問題ないのに、いざpublishすると503エラーになる)
※バージョン情報が分からなくなるかもなので、タグ指定も可能なのかなどもその際は検討したいと思います。
私が表題に関して取り組むのであれば、オレオレフレームワークとして開発しておき
そのGitHubのプロジェクトにあるREADME.mdに
「このフレームワーク使って開発するならば、こういうディレクトリ構造でこういう名前のファイルでやれよ」みたいなルールをつらつら書く感じにしますかね。
あくまでもフレームワークの使用方法みたいなところを記載しておく形ですね。
今回だとサンプルコードも記載したかったので、公開したいパッケージのプロジェクトと、そのパッケージを使用したサンプルプロジェクトを公開すると、目的が果たせそうな気がしました。
#10
@sk_さん (#7)
補足回答ありがとうございます。
そこで
- Laravelフレームワークに依存する自社用ライブラリAを開発し、
- 拡張アルチザンコマンドをライブラリAに定義、
- フレームワークのインストール後にライブラリAもインストール
- ライブラリAに定義したコマンドを実行する
とすることで、ここで言う必要なディレクトリ・ファイル雛形の作成等を行っていました。
調べてみたところ、package.jsonで定義できるnpm-scriptsに、OSコマンドなどを記載できるようでした。
なので初回構築をするバッチを作成しておいて、それを実行させるコマンドを定義して実行させると良いかもしれません。
これまでいただいた回答にこちらも組み合わせれば、より利用者側の負担を減らしつつルールに準拠したような形がとれそうです。
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。