![eyecatch](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgRcGvmTbhmso2QyvTtspbOrOYL8vMBlxyfopcTov5SSvjLDepqC_07ovnleibKmAmY2VmLJ6xu9XKYtc3pi6ck0HkSMYF8NvGtWXC-WI4sj0U-vjvHvChHqIv74vEIihWBLJhcMNaDGhRlJ552zoPk-Z3yyb88EkxSPksAS1nAoNlZ145PzVIxDlyYrHw/s1600-rw/git.png)
GithubでPrivateモードが使える様になったけど、オートデプロイは課金しないと使えなくて泣く泣く手動デプロイしている人、Gitのhook(フック)機能使ってオートデプロイさせればいいんですよ。
Githubは便利だけど、結局金払ってなんぼのシステムです。
ホームページ制作を仕事でやっている人であれば、1つのホームページで1プロジェクトのリポジトリ管理をしたいはず。
他にもミニマムなライブラリやミニゲームなどをたくさん作っていると公開しない場合は、Privateで運用するしかありません。
そんな時、クライアントなどがいる場合は当たり前ですが、公開にできない場合が多く、もどかしい想いをしている人もいるんじゃないでしょうか?
さらにドキュメントや色々な資料が50MBを超えると、
GIT LFSというモジュールをインストールして、Gitのストレージ領域に格納する設定をしなければいけませんが、チームプレイをやっているとトラブルも多くできれば使わない方が賢明なんですよね。
今回とある組織のホームページリファクタリングをお手伝いした時に、構築時点でGithubでソースコード管理を運用していたんですが、さすがに公開するわけにはいかないという事で、みんなでリモートリポジトリを管理できて、オートデプロイができて、お金が掛からない仕組みを導入してほしいという、なんとも無茶振りな願いを叶えるために、行った内容をブログに備忘録しておきたいと思います。
SSHアクセスできるサーバーを契約して、サーバーにGITがインストールされていれば、誰でもできる設定なので、お金をかけずにセキュアに環境構築をして運用したい人は是非参考にしてみてください。
仕様設計
Githubのプルリクエストによって、作業者ブランチをそれぞれmainブランチ(またはdevelopブランチやstageブランチ)にマージして、そのままオートデプロイ設定できていたんですが、
プルリクエスト機能は使わない様にするので、リモートリポジトリのdevelopブランチに直接PUSHをすると、自動的に本番公開用のリポジトリでPULLするというフローを考えました。
これまでプルリクエストによって、コンフリクトしている場合は回避できたのですが、今回はコンフリクトチェックをPUSHする人が直接行う必要があります。
コンフリクトしていると、本番公開にマージしないような分岐処理を入れることも可能ですが、とりあえず今回は時間優先で、オートデプロイのみに注力することにしました。
環境設定
今回は
さくらインターネットのサーバー契約で運用しているホームページで、SSHアクセスができる契約になっていました。
おまけにGITが事前にインストールされていたので、何の問題もなくGIT対応ができる状態でした。
リモートリポジトリの設置
同じサーバー内のユーザー権限内のフォルダで、WEB公開されない領域に、それまで使っていたGithubのリポジトリデータをcloneします。
※今回は、
~/gitというフォルダを作ってその中にリポジトリを設置しました。
cloneしたらそのフォルダに入って次のコマンドを打ち込みます。
git config --bool core.bare false
これで、リモートリポジトリができます。
githubから切り離すため、remote設定を削除しておきましょう。
git remote remove origin
※この状態であれば、githubをprivateで運用してもいいので、バックアップとして使う場合は、remoteを削除しなくても大丈夫です。
公開用GITフォルダのremote切り替え
次に公開フォルダのGITのremoteを、リモートリポジトリに切り替えます。
git remote set-url origin ~/git/*project/.git
*projectは、それぞれのプロジェクト名に置き換えてください。
これで、githubからの切り離しが完了です。
リモートリポジトリのhooks設定
developブランチにPUSHされたことをイベントで受け取って、そのまま任意のコマンドを実行するには、"*project/.git/hooks/post-receive"というshell実行用のファイルを作って実行権限を与えることで、簡単に構築できます。
その中身は・・・
#!/bin/sh
while read oldrev newrev ref
do
# developブランチにPUSHが行われたかを判定
if [ "$ref" == "refs/heads/develop" ]; then
echo "Detected push to develop branch"
# 公開リポジトリのパスを指定
PUBLIC_REPO_PATH="~/www/*project"
# 公開リポジトリのディレクトリがGitリポジトリかどうかを確認
if [ ! -d "$PUBLIC_REPO_PATH/.git" ]; then
echo "Error: $PUBLIC_REPO_PATH is not a git repository."
exit 1
fi
# 公開リポジトリのディレクトリに移動
cd $PUBLIC_REPO_PATH || { echo "Failed to change directory to $PUBLIC_REPO_PATH"; exit 1; }
echo "Changed directory to $PUBLIC_REPO_PATH"
# mainブランチにチェックアウト
git --git-dir="$PUBLIC_REPO_PATH/.git" --work-tree="$PUBLIC_REPO_PATH" checkout main || { echo "Failed to checkout main branch"; exit 1; }
echo "Checked out main branch"
# developブランチの変更をmainブランチにプル
git --git-dir="$PUBLIC_REPO_PATH/.git" --work-tree="$PUBLIC_REPO_PATH" pull origin develop || { echo "Failed to pull from develop branch"; exit 1; }
echo "Pulled changes from develop to main"
# 元のディレクトリに戻る(必要に応じて)
cd - || { echo "Failed to change back to original directory"; exit 1; }
echo "Changed back to original directory"
fi
done
echo "Finished post-receive hook"
*projectは書き換えてください。
少し長いコードになりましたが、もっとシンプルに書くことはできます。
ただ、いくつか落とし穴があったので、確認するecho文を埋め込んでみました。
落とし穴-1
今回のサーバーは、FreeBSDのOSが使われており、Bashが使えない環境でした。
そのため、ソース1行目には、
#!/bin/bashではなく、
#!/bin/shとしないと、エラーでオートデプロイが実行できません。
落とし穴-2
GIT操作は、checkoutとpullを行っているだけなんですが、どちらも
--git-dir="$PUBLIC_REPO_PATH/.git" --work-tree="$PUBLIC_REPO_PATH"とぷオプションをつけないと正常に動作しませんでした。
これは、cdしているんですが、作業環境を明示するオプションなので、つけておくと正常に動作するようになりました。
これで設定は完了です。
運用について
作業者は全てgithubから、今回新設したリモートリポジトリにremote設定を切り替える必要があるので、上記作業が完了できたら次のコマンドを実行しておきましょう。
git remote set-url origin ssh://*アカウント名@サーバードメイン:~/git/ttc/.git
※アクセスは適宜書き換えてください。
実際にオートデプロイされるのか確認してみます。
ローカル作業環境で、ファイルを更新して、コミットされた状態で以下の操作を行います。
git push origin ※自分リポジトリ:develop
これでエラーが表示されなければ、本番公開をブラウザで見てみましょう。
無事に更新されていれば、オートデプロイ完了です。
セキュアポイント
ちなみに、GITリポジトリの公開領域は、必ず.gitのある階層に、publicなどのフォルダを作ってそのフォルダを公開するようにしましょう。
.gitフォルダ自体が公開されてしまいますからね。
あとがき
AWSを含めてVPSなどのサーバー契約をしている場合は、自分でGITインストールすれば、公開サーバーにGITリモートリポジトリを仕込んで便利にソース管理とデプロイ管理までできてしまうので、今の時点でFTPを使って、デプロイ作業をやっている人にはオススメです。
もちろん、別サーバーにリモートリポジトリをセットしてもできますよ。
1サーバー運用でもできるという今回のオートデプロイ仕様、きっと同じことやっているプロジェクトもたくさんあると思いますが、改めて自分で設置した足跡を残しておきました。
不便は人的ミスも招くのでできるだけ自動化をするのは、最近主流の環境設定ですからね。
0 件のコメント:
コメントを投稿