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