問題点
- 開発を始めるまでが大変（新規メンバー、3ヶ月後の自分）
- アップロードが衝突する（開発用サーバ）
- 先祖返り（デグレード）
- Issueベースでタスクを振りたい
- バグが起きた時点を知りたい
デプロイで解決
- 開発を始めるまで
- Gitさえ分かればデプロイされる
- アップロード衝突
- Gitのブランチで独立
デプロイで解決
- 先祖返り（デグレード）
- 手動アップロードからの解放
- タスクベースでタスクを振りたい
- GitのIssueとPR、デプロイの紐付け
- バグ発生時
- リリースをそれぞれデプロイ
開発を始めるまで
-
新規メンバーに環境を揃えてもらいたい
-
修正箇所は検討がつくのに整備が大変
-
3ヶ月前のコードがわからない
-
3年前のコードは全然分からない😫
-
自動デプロイ🔧
-
Gitさえコミットできればデプロイされる
-
一部のロジックに注力できる
アップロード衝突
-
同時に開発環境を使うことができない
-
「作業を止めてもらっていいですか？」
-
3人ぐらいならまだしも、5人、10人となると…
-
どこにテストしているかわからない
-
自動デプロイ🔧
-
Gitブランチごとに独立したデプロイ
-
サブドメインやディレクトリで分割
-
ファイル、DB、を分ける
先祖返り（デグレード）🐛
-
先祖返りを起こしてしまう
-
アップロードした人が古いファイルを持っていた
-
ファイル管理が大変
-
Gitの導入だけでもかなり解決するが、手動部分でオペミス
-
自動デプロイ🔧
-
アップロードは「必ず」Gitのものをアップする
-
Gitに必ず注力することになる
Issueベースでタスクを振りたい
-
Issueベース
-
「料金計算の修正」「フッターデザインの修正」
-
Gitのブランチ化、マージで衝突を防ぐ
-
それぞれ同時並行で進むと確認が大変（アップロード衝突と同じく）
-
自動デプロイ🔧
-
Gitブランチごとに独立したデプロイ
バグが起きた時点を知りたい
-
「今回の修正をお願いしたところ、全部の計算がおかしくなりました」
-
今回の修正が計算をおかしくしたのか、もともとそうだったのか
-
「お客様への説明責任」と「原因の追跡」を行いたい
-
旧バージョンをアップすれば再現
-
自動デプロイ🔧
-
リリースバージョンごとにデプロイ
自動デプロイ
- 開発の問題を解決し、持続的な開発を行いたい
- ソフトウェアの寿命
- 開発者「2年」 発注者「10年」
- ただし長年のメンテは大変…
- 開発者のスケールアウト
開発者のスケールアウト
-
開発メンバーを増やしたい -> 開発者のスケールアウト
-
テストの自動化、チームの組織化
-
タスクの分割を行えばスケールできる
-
イメージとしてはWordPressのプラグインのようなエコシステム（相互独立性）
まとめ
-
開発を取り巻く環境を良くしたい
-
より良いシステムを より安価に提供したい
-
利用者の利益につなげたい
-
更に先
-
システムテスト自動化
-
テストエンジニアのスケール