この記事を書いたきっかけ
筆者は普段Flutterでモバイルアプリの開発をしたり、Next.jsやLaravelでウェブアプリケーションの開発をしています。基本的に似たような開発をする方達は、Gitを使うためにGithubやBitbacketなどは必ずと言っていいほど用いるはずです。
しかし、WordPress制作をするWebサイト制作のようなプロジェクトではGitの扱いが蔑ろになっており、直接ファイルをサーバーにアップロードするようなチームも存在しました。
筆者も過去にWebサイト制作の仕事を個人で受注した際、「ローカル環境」や「Git」は存在しない上、「タスク管理」もエクセルの表でなんとなくされていました。
そのプロジェクトに「Git」は導入することができたものの、「ローカル環境」が用意しきれなかったため結局ファイルのアップロードは直接テスト用のサーバーに上げるしかなかったのです。
記事の対象者
-
Wordpressで普段開発をしていて以下の悩みを抱えている方
- Gitを使ってみたい
- 手動アップロードして先祖返りを経験した
- 修正したはずの作業のバックアップが無くて苦しい経験をした etc...
-
普段Web制作をしていないがこれからWordpress環境で開発してみたい方
環境全体図
まずは、環境の全体図を表示してみます。
ローカル環境
ローカル環境は、WordPress専用の「Local」というアプリケーションがあるのでそちらを利用します。
ソースコード・資材管理
今回はGithubを用います。
アカウントが未設定の方はこちらから作成してくださいね
(P.S. Githubのアカウント作成時はとてもワクワクします)
Githubでは、1つのプロジェクトを「リポジトリ」といいます。
しかし、単純にリポジトリを作ってしまうと個人のプロジェクトとして扱われてしまいます。
これをチームで扱うために、Organizationというものを設定します。
アップロードサーバー
こちらは当然WordPressです。
細かい設定などは他のQiita記事や技術ブログに委ねます。
テスト用と本番用2つのサーバーを用意する必要はありません。
⚒️ 環境構築編 ⚒️
筆者はMacOS環境で動かしているため、Windows, Linuxユーザーは適宜ディレクトリパスやコマンドを置き換えてください。
1. Githubの準備をしましょう
1-1. Organizationの作成
まずは、Organiaztion(チーム)を作成しましょう。
右上のアイコンをクリックしたらメニューが出るので、「Your Organizations」をクリックしてください。
次に、「New Organization」をクリックし、作成をしてください。特段こだわりがなければ一旦Freeプランで良いでしょう。無料プランであっても大きい制約やセキュリティの問題は発生しません。
1-2. リポジトリの作成
Orcanizationの登録が完了し、Orcanizationのトップ画面へ行くと以下のような画面が出るため、こちらのNewをクリックしてリポジトリ(プロジェクト)の作成をしておきましょう。リポジトリの作成をする際、「public(一般公開)」「private(非公開)」の選択を迫られるため、「private(非公開)」を選択してください。
1-3. チームメンバーの招待
次に、チームメンバーの招待をします。
リポジトリのヘッダーにこのようなバーがあるので、一番右のSettingsをクリックしてください
次に、「Collaborators and Teams」をクリックしたら以下のような画面になると思うので、「Add People」で誘いたいメンバーを招待してください。
Githubの検索は、「その人のメールアドレス」もしくは「Githubアカウント名」で登録が可能です。
2. ローカル環境の準備
それではまず、Localアプリをダウンロードしましょう。
自分の環境に合うものを選択してください。
2-1. アカウント設定
次に、アプリを立ち上げたらアカウント作成を要求されます。
問題なければ、GithubもしくはGoogle連携でアカウントを作成しておきましょう。
(もちろんメールアドレスで設定しても問題ないです)
完了したら、今度はLocalを立ち上げて左上のアイコンからログインをしましょう。
2-2. プロジェクトの作成
Localは、Localでプロジェクトを立てるやり方と、WordPressからzipでプロジェクトを共有するやり方があります。今回は、Localでプロジェクトを立てます。
Create a new siteをクリックします。
次に、左のメニューを選択し、右下のContinueをクリックしてください。
進んでいくと、PHP, ウェブサーバー, MySQLのバージョン等聞かれます。
指定するものがあればCustomから指定し、特段ないのであればPreferredのまま進んでください。
登録が完了したら、自分のローカルに以下のようにローカルにワードプレス環境ができていると思います。私の場合、「kurogoma」というサイト名で作ったためこのようになっています。
2-3. Gitにアップロードしよう
ちなみに、Localでプロジェクトを作成する際、「どのディレクトリに保存するか」という設定もありましたが、Mac OSの場合デフォルトで以下に格納されていると思います
/Users/あなたのユーザー名/Local Sites
その中に、先ほど作成したローカルプロジェクトがあるためそれをターミナル(コマンドプロンプト)で開いてください。以下のようにpwd
コマンドで対象プロジェクトの場所にいればOKです。
% pwd
/Users/あなたのユーザー名/Local Sites/kurogoma
では次に、先ほど作成したGithubのリポジトリを見てみましょう。
以下のような画面が出ているはずです。
ただ、一旦ここは無視して大丈夫です。以下のように上から順番にコマンドを入力してください。
% git init
% git add .
% git commit -m "🚀 first commit 🚀"
% git branch -M main
% git remote add origin リポジトリのURL
% git push -u origin main
以下のコマンドについては、Githubの画面にも出ているはずなのでそのままコピペしていただければ良いと思います
git remote add origin リポジトリのURL
最後のコマンドまで実行した後、Githubのページをリロードしてみてください。以下のように反映されていると思います。
ここまでできれば、ローカル環境の完成です。
💻 本番環境構築編 💻
WordPressを構築するため、まずは以下のリンクからデスクトップアプリをインストールしてください
インストールできたらWordPressにログインし、新規サイトを立ち上げてください。
立ち上げが完了したら以下のような画面になると思います。
(サイト名は、先ほどLocalで作成したものと同様に設定します)
試しに、右上にある「サイトを表示」をクリックしたら以下のようなデフォルトのサイトが表示されると思います。
ここまでできれば一旦完了です。
基本的に直接本番環境を触ることはせず、次のセクションでLocal -> 本番への連動を自動化しましょう。
🌏 Local → 本番への連携 🌏
まず、Localの状態を確認します。
右上のOpen siteをクリックしてみてください。
そうすると、以下のようにこちらもデフォルトサイトが表示されます。
では、こちらをうまく連動するようにしましょう。
なんと、Localと本番を繋げられる便利なプラグインがあります。
手動でも構いませんが、こちらを使うことでボタン操作のみで簡単に配信できます。
🌳 ブランチ運用モデル(開発フロー) 🌳
最終的に本番で確認したい場合は、先ほどのAll-in-one-Migrationのツールを活用してください。
ここでは、ローカルで開発する際にどのようにすればスムーズな開発ができるか示します。
Github(Git)には、ブランチという概念があり、個人の作業環境を分けることができます。
かなりありきたりな話なので、ブランチの詳細については以下の記事を参照してください。
また、ブランチにはそれぞれ「ブランチモデル」というものが存在します。
「git branch model」のように検索すればそれっぽい記事がある程度出てきますが、今回は以下のようなブランチモデルを紹介します。
ブランチモデル
- mainブランチ
- 先ほどのAll-in-One-Migrationをしてデータ移行をするブランチ。つまり、「本番環境と完全に一致している環境」を指します。子には
develop
ブランチを持ちます
- 先ほどのAll-in-One-Migrationをしてデータ移行をするブランチ。つまり、「本番環境と完全に一致している環境」を指します。子には
- developブランチ
- Local環境は全てこのブランチを親とします。
main
が親となります
- Local環境は全てこのブランチを親とします。
- releaseブランチ
- こちらは必須でないのですが、プロジェクトの方針として10/1リリースと11/1リリースのページがそれぞれあるとしたら必要になるでしょう。親は
develop
です
- こちらは必須でないのですが、プロジェクトの方針として10/1リリースと11/1リリースのページがそれぞれあるとしたら必要になるでしょう。親は
- featureブランチ
- 基本的な機能開発で使うブランチです。親は、
feature
もしくはdevelop
です
- 基本的な機能開発で使うブランチです。親は、
- bugfixブランチ
- 不具合対応系のブランチです。親は
feature
もしくはdevelop
です
- 不具合対応系のブランチです。親は
- hotfixブランチ
- 緊急対応用ブランチです。親は
develop
が好ましいですが、main
を直接の親としても構いません。しかし、その場合はdevelop
への更新も忘れないようにしてください
- 緊急対応用ブランチです。親は
それでは、上記の内容をツリー形式で整理してみます。
main
├── develop
│ ├── release
│ │ └── feature
│ ├── feature # releaseブランチが不要な場合
│ │ └── bugfix
│ └── hotfix
└── hotfix # 相当緊急の場合
運用については、以下の流れで運用します。
共通
- これまでの環境構築をした直後の場合、mainが最新です
- エンジニアが作業に入る前までにdevelopブランチを作成します
ブランチの作成方法は、2つあります。
コマンドラインでブランチを作成する
コマンドでブランチを作成する場合、以下のコマンドで作成可能です
# 現在のブランチを確認
$ git branch
* main # *がついている行が現在選択されているブランチです
# 作成+切り替え
$ git checkout -b 作りたいブランチ名
# リモートへの反映
$ git push --set-upstream origin 作りたいブランチ名
Githubブラウザ上でブランチを作成
まず、Githubでリポジトリのページを開いてください。そうすると、以下のようなブランチのボタンがあるのでクリックしてください(mainと書いてあるところ)
次に、Find or create a branch...
と書いてある箇所に作りたいブランチ名を書きましょう。
そのごCreate branch: ブランチ名 from main
と表示されている箇所をクリックして作成してください。
💡 ローカルへの反映
これだけでは、まだ手元の環境(ローカルリポジトリ)に反映されていません。
ローカルへの反映はコマンド操作で行いましょう
$ git fetch --prune
$ git switch 作ったブランチ名
それでは、上記を前提にブランチモデルの解説をします。
releaseブランチありの場合
- リリース時期、もしくは機能単位で以下のようなブランチを切ります
-
release/xxx-xxxx
(機能名を英語で) -
release/yyyyMMdd
(リリース日を記載)
-
- 上記ブランチから、
feature
ブランチを以下のように切る-
feature/xxx-xxx
(機能名を英語で) -
feature/チケット番号
- Github Issuesの場合、
feature/issue-10
- Jiraの場合、
feature/JIR-123
- Github Issuesの場合、
-
-
feature
ブランチからrelease
ブランチにプルリクエストをする -
release
向けの機能が全て揃い次第、develop
ブランチへ代表者がプルリクエストをする - 上記PRの差分を確認し、マージをする
- 動作確認をする
-
main
ブランチへ代表者がプルリクエストをする - 差分を確認し、マージをする
-
All-in-One-Migration
で本番へ反映する- プラグインの確認
- その他設定項目の確認
- 最終的な動作確認をする
- リリース 🎊
releaseブランチなしの場合
-
develop
ブランチからfeature
ブランチを切る -
feature
からdevelop
へプルリクエストをする - 全ての機能が揃ったら
develop
の状態でテストをする - 完了したら、代表者が
develop
からmain
へプルリクエストをする - 差分が正しいか確認し、マージする
-
All-in-One-Migration
で本番へ反映する- プラグインの確認
- その他設定項目の確認
- 最終的な動作確認をする
- リリース 🎊
最後に
長かったと思いますが、読んでいただきありがとうございました。
もし、「ここがわかりにくい」「この説明を増やしてほしい」などリクエストがあれば
どんどん更新していこうと思います!
Happy Coding!