💭

ひとりぼっち開発の運用フロー

2024/08/19に公開

ブランチ戦略

  • 各環境にどのコードベースが適用されているか、すぐにわかる
  • 運用ルールがシンプルで、すぐにわかる

→ github-flowをベースにやりやすいようにアレンジを加える

各ブランチの役割

  • main
    • 常に最新のコード。直接pushせず、feature or releaseブランチのマージでのみ更新される。
  • feature
    • 機能開発やデバッグなどをrelease以外のすべての作業をやる
  • release
    • ファイルのコンパイルやリリースノートの作成

タスク管理

タスク管理はgithub issueとgithub milestoneを使っています。

github issue

issueはfeatureブランチ/releaseブランチと1:1で紐づくようにしています。
なるべくissueの粒度は同じ程度に保つようにしていますが、機能開発の類は気づくとバカデカタスクになっていたりするので、たまにタスクを分解して再度登録するようにしています。

なおissueのlabelはテンプレを作っていて、こんな感じです。

github milestone

milestoneは毎週月曜日にgithub actionsを使って自動で「今週分のマイルストーン」を作っています。
週末に今週も頑張ったな~とモチベ管理するためにやっていますが、複数人運用になったらもうちょっとスクラムっぽいものを作りたいと思っています。

リリース管理

リリース管理はgithub releaseとgithub webhookを組み合わせて自動デプロイするようにしています。

stg環境とprd環境のソースコードはgithub releaseとgit tagを組み合わせることで、今どの状態か常にわかるようにしておく。
stg環境はgithub releaseのプレリリースと紐づき、prd環境はgithub releaseのlatest releaseと紐づく。

今後の展望

jenkins等を用いてゴリゴリにcicd環境を作るのにあこがれも抱きつつ、人員が増えた時の夢としておく。
リリースノートの作成やコミットメッセージの標準化などに使用しているツールは以下の記事に書いてある。
https://zenn.dev/ransakata/articles/fb2ca30e4dc0f5
複数体制になったらテストをローカルで実施するのやめたいな。

参考

https://var.blog.jp/archives/81458797.html
https://zenn.dev/shelly/articles/e95d185dfb56eeb8ecff
https://ceblog.mediba.jp/post/680296068897964032/2年間育てあげたブランチ戦略を人類のために公開する

Discussion