ふだんの開発では，稼働中のシステムに影響を与えないように開発中の新機能や新システムを共存させながらちょっとずつデプロイして進めている．どんな事を考えてやっているか記しておきます．
フィーチャートグルを使う
- すべてのコードが本番環境に入っているけど無効化されている状態で開発を進める
- ブランチをたくさん作るのに対する考え方で，フラグを有効にすると開発中の機能を使える
- スタッフなら有効にしたり，フィーチャーのオンオフを選べる画面を作ってたこともある
- フィーチャーブランチを利用した開発はチームを継続的インテグレーションから遠ざける – ゆびてく
- FeatureToggle
- 完成したらフィーチャートグルに関係なく全員に有効状態にして完成
- フロントエンドの施策で，実際のデータやインフラ構成でどれくらいスピードが出るかわからないときに，ひとまずフラグをオンにすると動く形でデプロイしたりとか
レイヤの下の方から作っていって最後に外部から呼べるようにする
- データベースの設計，モデルの実装，アプリケーション層の実装，と進めて，最後に表から呼べるようにするためWebkAPIを作る，という形で下から順番に作っていき，小分けにマージしていく
- 最後につながるまでは，本番環境では動いてないが，実装が置いてあったり，CIが通っていたり，という状態で進む
画面はフィーチャートグルで隠しておき，それとは別に下のレイヤから作っていく
- 前2つの合わせ技で，トンネルを両端から掘っていくようなイメージ
なにが起きるかわからないのでtry catchしておく
- 開発中のリリース前のコードが他の箇所に影響を与えると困るので，とりあえず呼び出し部分をtry catchしてエラーを記録しておくという技
- 雑に作っているわけではなくて，リスクを下げたいという話で，開発中でユーザーの役にも立たない機能のために巻き込まれて使いたい機能が使えなくなると誰も得していない
- 全体が止まるよりは影響が小さな箇所にとどまるほうが便利
新しいモデルに徐々に載せ替えていく
- 理想的な綺麗なモデルオブジェクトを作り，簡単なところから新しいモデルを呼ぶように変えていく
- 同じ問題を解くためのコードが一時的に2つ存在することになるが，新しい方に移し替えると，新たな問題を解けるようになっている
- マイクロサービスアーキテクチャにも似た話があったと思う．締め殺しパターン
ペース感
- 1日1個進められるくらいの規模に問題を分割して,1日1個か2個くらいpull resuestを投げている
- 計画を立てたり，コードレビューを通す時間も含めて1日なので，一度の実装にかかる時間は多くても1〜2時間くらい
- チームで開発してるとまとまったコードを書ける時間を確保するのが難しいので，なるべく小分けにして，早くコードレビューに出して他人に処理を渡してしまったほうが得，という話もある
- レビューしてもらってる間に別のところを進められるような手順を考えておけるとよりよい
ビッグバンリリースをしない
- いろんなテクニックを書いたけど，一言で言うと，ビッグバンリリースをしないという話
- いきなり本番環境にでかいコードを出すと緊張し，動作実績のない大量のコードをいきなり動かすと不具合も出やすく，メリットがないので，絶対にちょっとずつ進めるようにしている
気持ち
- いまいち伝わらないと思うけど，走ってる車にとびついてタイヤと一緒に回転しながらタイヤを入れ替えるような気持ちでやっている
車のタイヤを入れ替えたかったら、止まればいいけど、走ったまま入れ替えようとすると、タイヤに飛びついて、タイヤと一緒に高速回転しながらタイヤ入れ替えることになると思う。そういう雰囲気が出てきてる。
タイヤ - hitode909の日記
