プロジェクトの進行管理の為にサーバーのバージョン管理の必要性
弊社のWebサイトをWordPress特化型ホスティングサーバー「Kinsta」に移行するタイミングで、サーバーのバージョン管理の見直しを実施しました。
弊社Webサイトで利用しているWordPress特化型ホスティングサーバー「Kinsta」はこちら
「Kinsta」に移行するにあたり「Kinsta」を調べていると、「Kinsta」は本番環境と同じ要件のステージング環境の作成が可能であり、「GitLab」のCI/CDを活用して本番完了とステージング環境に自動デプロイ出来るんですよね。
Kinstaの内容がGitLabで管理してるバージョンをそのまま反映出来るようになったら便利だと思って、見直しを実施する事にしました。
GitLabで管理している最新バージョンが常にデプロイされるので、現在の実装状況を管理しやすくなるし、アップロード忘れや先祖返りのリスクも軽減に繋がるからです。
更にステージング環境が本番環境と同じ内容で作られているので、ステージング環境で動作確認が取れている内容は本番でも動作しているので、ステージング環境で動作確認が出来たら、mainブランチにmergeするだけで本番反映が出来るようになります。それって色々と便利だと思いませんか。
お使いのGilLabの環境やKinstaの設定により、詳細は違いますが、CI/COでの自動デプロイは下記の感じの手順で実行されていきます。
- ①GitLabとKinstaのSSHキー(公開鍵)を取得して、お互いのSSHキー（公開鍵）を登録しあう。
- ②KinstaのSSHキー（秘密鍵）をGitLabに登録
- ③Gitlabのプロジェクトをclone又は、KinstaのファイルをGitlabの空プロジェクトへPush
- ④.gitlab-ci.ymlに自動デプロイのプログラム記載
- ⑤GitLabへPush
GilabのサーバーによってはGitLab-runnerを必要だったり、Gitで管理したくないファイルがある場合は.gitgnoeを使用する必要やthemeディレクトのみを管理したい場合は.gitの設置場所の変更が必要になりますが、基本的にはこのような手順で実装を行います。
これまでは、実装により更新漏れなどを理由にGitLabで管理しているファイルと本番で公開しているファイルに差分が発生するリスクがありましたが、自動デプロイの導入により、リスクを減らして運用が可能になりました。
また、実装手順もかなり簡素化されるようになっています。
今までは、下記のようになっていました。
- GitLabのステージングブランチへのPush、
- Pushした内容のファイルを各環境でFTPで接続、WInMerge等で更新ファイルの差分を確認。
- 更新ファイル以外も念のため、差分がないか確認。
- 問題なさそうだったら、FTP経由でアップロード
- 反映確認
- GitLabのmainブランチへstagingの内容をマージ
- Pushした内容のファイルを本番環境でFTPで接続、WInMerge等で更新ファイルの差分を確認。
- 更新ファイル以外も念のため、差分がないか確認。
- 問題なさそうだったら、FTP経由でアップロード
- 反映確認
手順が10個もあってかなり煩雑な更新です。
しかも、GitへのPush以外は全て目視確認が必要で作業内容も単調な為、ミスが発生しやすい状況でした。
デプロイの自動化した事により、下記の手順に替わりました。
- GitlabのstagingブランチへPush
- Kinstaのステージング環境が自動デプロイ(自動でKinsta側でPullの実行が行われます。)
- 反映確認
- GitLabのmainブランチへStagingの内容をマージ
- Kinstaの本番環境が自動デプロイ(自動でKinsta側でPullの実行が行われます。)
- 反映確認
手順が6個に減りました。
それも、2と5に関しては、Kinsta側で自動で行うので、実質手順は各GitLabへの Pushやmergeと反映確認の合計4手順で済みます。
今まで、ないがしろにされていた、サーバーでのバージョン管理が出来るようになっただけでなく、反映手順もかなり簡素化され、実装ミスの発生も起こりにくい環境になりました。
皆さんもGItLabのCI/CDを活用してサーバーのバージョン管理と自動デプロイを行いませんか、実装に興味を持って頂いたかたは是非お問い合わせ下さい。
