複数人でPHP(Laravel)のシステム開発を行う際、以下のような方法で開発ソースの管理を行うと効果的です。
Contents
ディスプレイ広告
開発ソースの修正、変更内容の把握、管理
ツールの選択
GitHub または GitLab
理由
- バージョン管理:
Gitを使用してソースコードの変更履歴を管理できます。 - ブランチ機能:
開発作業をブランチごとに分けて行い、複数人での並行開発が可能です。 - プルリクエスト/マージリクエスト:
変更内容のレビューと承認のフローを構築できます。
Gitの基本的なワークフロー
- ブランチ作成:
各開発者は新しい機能やバグ修正のためにブランチを作成します。 - コード変更:
ブランチ内でコードの修正や新規機能の実装を行います。 - コミット:
変更内容を小まめにコミットして履歴を残します。 - プルリクエスト/マージリクエスト:
完成したら、レビューのためにプルリクエスト(GitHub)またはマージリクエスト(GitLab)を作成します。 - コードレビュー:
他の開発者がコードをレビューし、問題がなければマージします。
変更内容をシステムステージング環境に反映する手順
ツールの選択
GitHub Actions または GitLab CI/CD
理由
- 自動デプロイ:
コードがリポジトリにマージされると、自動でステージング環境にデプロイされるように設定可能です。 - テスト実行:
デプロイ前に自動テストを実行し、エラーがないことを確認できます。
ステージング環境への反映手順
- CI/CD パイプライン設定:
.github/workflows(GitHub)または .gitlab-ci.yml(GitLab)ファイルにパイプラインの設定を記述します。 - テスト実行:
パイプライン内でユニットテストや統合テストを実行します。 - デプロイ:
テストが成功したら、ステージング環境へ自動デプロイします。
Laravelのソース管理を行う対象ディレクトリ、除外ディレクトリ
対象ディレクトリ
- app/
- bootstrap/
- config/
- database/
- public/
- resources/
- routes/
- storage/(一部のみ。storage/logs や storage/framework は除外)
- tests/
- vendor/(Composerで管理されるため、除外)
除外ディレクトリ
※以下は一例です。
- .envファイル(環境変数ファイル): 環境ごとに異なるため、バージョン管理から除外します。
- node_modules/ディレクトリ: npmパッケージを管理するためのディレクトリ。
- vendor/ディレクトリ: Composerで管理される依存関係。
- storage/logs/ディレクトリ: ログファイル。
- storage/framework/ディレクトリ: 一時ファイルやセッション情報。
.gitignoreの設定例
※以下は一例です。
/vendor
/node_modules
/.env
/.env.*
/storage/logs
/storage/framework/sessions
/storage/framework/views
/storage/framework/cache
結論
GitHubとGitHub Actions、もしくはGitLabとGitLab CI/CDの組み合わせが、開発ソースの修正、変更内容の把握、管理、およびステージング環境への反映に最適な選択となります。理由としては、これらのツールは豊富な機能と柔軟性を持ち、チームでの効率的なコラボレーションと自動化をサポートするためです。
※参考にする場合は自己責任でお願いします。
ディスプレイ広告
ディスプレイ広告