まず始めに言いたいことは、もともとあった物を悪くいうつもりはないという事です。変化は現状の否定とも言えますが、その当時の判断を行った人を悪くいうつもりはありません。

CI導入のコツ

私の場合は
・一気にやろうとしない
・やりやすいこと、好きなこと（熱意を持てる）から始める
・わからないことはとりあえずbest practice

です。

どういう状況だったか

入社前の状況
プロダクト
リリース後1年間程度

エンジニア
3名（取締役兼任1名・ジョイン直後1名・業務委託1名）

CI周り
Branch: master直push
Build: Test code 0 / Build jobなし
Deploy: AWSコンソールでインスタンス起動、sshkey書き換え、サーバーログインしてビルドコマンド実行、ELB切り替え、元インスタンス停止

何をしたか 1 branch policy

まずブランチを切るところから始めました。
シンプルにmain - topic-branchのみの構成です。
これで、相互に修正をレビューを行えるようになりました。
いきなり全てやれないので、仕組み化は徐々にです、一番簡単なのは会話なので、「これテストしてる？」みたいな会話をプルリクのコメントで残していくことから始めました。

何をしたか２ ツール導入

Jiraを導入しました。もともと興味があったのと、リポジトリがbitbucketだったのと、Trelloのチケット管理だと、案件を貯めていく構造に適していないと感じたので。
これでticketからbranchを切れるようになりました。
地味ですがチケットとPRが関連づけられていると、CSチームへの修正の説明時にパッとプルリクに飛べたりして、経緯をきちんと確認できたり、エンジニアが行なった仕事の結果を追うことで仕様の説明ができたりするようなメリットがありました。

何をしたか3 テスト

テストコードからではなく、テストのドキュメントのテンプレを用意し、GoogleDriveに貯めて行きました。
その後、流石に辛すぎるね、大規模な変更できなくなるね、ってことでMinitestを追加し、現在はrspecでのテスト数が2400件になりました（カバレッジはまだまだですが）。

何をしたか4 デプロイ

もともと一番辛かったのがデプロイで、APサーバログインしてコマンド実行、AWSコンソールでELBのtarget付け替えるの怖すぎでした。
また、緊急の修正をサーバー内のrbファイルを直で修正し、後でリポジトリのコードを直すという最終奥義がありましたが、入社して比較的すぐ封印しました。

とにかく手間が多く、ミスが致命的でミスりやすい状況だったので、手元で打つコマンドをshellにしました、開発者のlocalhostからsshでサーバログインしてaws-cliで諸々付け替える。

デプロイは今はもっと進化していて、staging環境起動とかできるようになっているのですが、ちょっと長くなってきたので別の記事で書きます。

CIをContinuous改善する

この手の変更は、
・最初は窮屈。が慣れてくると戻れなくなる系
・圧倒的利便性に感謝系
があるのですが、色々辛い状況の場合、その時々の辛さに合わせて興味あったりするものから手をつけていくのがいいのではないでしょうか。

また、普段からメンバーと課題感を共有し、辛みを共感し課題解決に向けてテンションを高めておくことも大事なのではないかとこうして振り返ってみると思いました。

「このXXやばいね」みたいなことをよく言っている気がします。