こんにちは、エンジニアの大地です。
今回は弊社エンジニアチームの開発サイクルについてご紹介します。Issueの起票から開発、リリースまでの流れを詳しく解説します。
Issueの起票
弊社では、タスク管理にGitHubのIssueを使用し、Projectsのダッシュボードで一覧管理しています。Issueの起票には主に2つの経路があります。
事業部からの発案
PO（プロダクトオーナー）が事業部からの要望を吸い上げ、必要な情報を揃えた上で起票します。この経路では新機能の開発や既存機能の追加実装が多いです。
エンジニア主導の発案
スロークエリが発生している機能のパフォーマンス改善や、アラートが発生している機能の修正タスクとして起票するケースです。この経路は主にTechIssueとして扱われます。
開発
ブランチの運用ルール
大まかにルールとして決まっているものは以下の2点です。
- 大規模な開発: メインブランチからdevelopブランチを切り、さらにそこからfeatureブランチを切って開発を行います。
- 小規模な開発: メインブランチから直接featureブランチを切り、開発を行います。
プルリクエスト作成
メインブランチへ直接コミットはできないようにしており、必ずプルリクエスト（PR）を作成します。PRは最低1人以上のレビュー＆承認が必要です。
また、レビュアーの負担を軽減するため、できるだけ小さい単位でPRを作成するように心がけています。
CI
プルリクエスト作成時には、PHPStanによるLintチェックとPHPUnitによるテストコードの実行が自動で行われます。
Lintチェック
PHPStanによるLintチェックを導入することで、以下のような恩恵を受けています。
- コード品質の向上: コーディング規約違反や潜在的なバグを早期に検出し、コードの品質を維持します。
- 一貫性の確保: チーム全体で統一されたコーディングスタイルを保つことで、コードの可読性と保守性が向上します。
- レビュー時間の短縮: 人間のレビューアが見逃しがちな細かい問題を自動的に検出し、レビュープロセスを効率化します。
テストコードの実行
PHPUnitによるテストコードの実行により、以下のような利点があります。
- バグの早期発見: 変更が既存の機能を破壊しないかを確認でき、バグの早期発見と修正が可能です。
- 信頼性の向上: テストが通過することで、コードの信頼性が保証され、本番環境へのデプロイ時の安心感が増します。
- 継続的な品質保証: 新機能追加や変更があっても、一貫した品質を保ち続けることができます。
これらのCIプロセスにより、コードの品質を高い水準で保ちながら、効率的に開発を進めることが可能になっています。
ステージング環境
弊社では、本番環境と同等のステージング環境を用意しています。ローカル環境と本番環境の差分による予期せぬバグを防ぐため、ステージング環境での確認を行います。また、ステークホルダーの意図通りに動作するかを確認する場としても機能しています。
リリース
ステージング・本番ともにCDが整備されており、ほぼ自動で各環境にデプロイされます。具体的なリリースフローに関しては以下の記事で紹介しています。
デプロイ後、Datadogなどでサーバーへの負荷状況やエラーの増加等をしばらく監視し、本番での動作確認を行なった後、問題なければSlackで全社へのリリース報告を行います。
まとめ
今回はタンプの開発サイクルについてお話ししました。弊社では、新規機能の開発と既存機能の改善を両立しながらサービスを一緒に作っていくメンバーを募集しております！
少しでも興味を持っていただけたら、各種募集記事からお気軽にご連絡ください！
エンジニア採用サイト：https://tanp.jp/company/engineer
タンプ Twitter：https://twitter.com/gracia_tanp
