DX向上について考えてること
- Oct 01, 2019
- Poem
会社での仕事の大半はDX向上な気がしているので、普段やってることについてまとめていく。
DX: Developer Experience （開発体験）は重要だ にDX向上のメリットについて書いてあるのだが、具体的な作業は何かについて書いていないので自分なりのやり方を書いていく。
最近ずっとRailsばっかだったので、Railsプロジェクトをイメージして書く。
- 環境構築をなるべくDockerでできるようにする
- 再現性の高い環境構築手順を作成する
- Editorconfigを入れる
- インフラ構成を整理する
- 安全にDeployできるような仕組みを作る
- CircleCIなどCIサービスを入れる
- GitFlowを入れる
- 明らかに使ってないファイルを削除する
- 使用してる外部サービスを洗い出しておく
- ソースコードに埋め込まれている鍵をenvに移す
- Sentry などエラーを検知出来る仕組みを導入する
- Linterを入れて変更を少なく定期的に修正していく。
- Rspecのようなテストツールを入れる
- dependabot を入れる
- pull pandaを入れる
- 静的解析ツール(phanなど)を入れる
- NewRelicなどの監視ツールを入れる
- 事業リスクになりそうな箇所を洗い出して工数を取ってもらうべく動く
- 時間を見つけてロジックが複雑な部分をリファクタリングをしていく
- errorやdeployやcommit通知をslackに流す
- git-pr-releaseを入れる
安全にDeployできるような仕組みを作る
AWS ECSのようにコンテナマネージドサービスの場合はCircleCIから叩けばよいだろうし、そうでなければとりあえずdeploy用のサーバーを立ててcapisoranoでdeployしちゃっても良いと思う。
大事なのはlocalに依存しないことと再現性のあること。
使用してる外部サービスを洗い出しておく
意外とこういうのの洗い出し大事だと思う。使ってないコードの削除も捗るし、抽象化もしやすい。
事業リスクになりそうな箇所を洗い出して工数を取ってもらうべく動く
技術的負債の説明をできるのはエンジニアしかいないので、対応するかどうか置いといて、きちんと伝えることは大事だと思う。
エラー通知やdeploy通知をslackに流す
DX向上はエンジニア以外はわからないので、「きちんと作業してる」ということを伝えるのは大事だと思う。
DX向上はエンジニアのための作業だけど、ちゃんとエンジニア以外にも「伝える」こともエンジニアとして大事なんだろうなぁと思う次第