はてなマンガチームは人数が多いチームで、関わる人のロールも多い。
手元の開発環境はDockerを使って構築しているのだけど、それを起動するメンバーは(エンジニア or デザイナ) × (社員 or アルバイト) のかけあわせで、いろんな立場の人がいる。もうすぐインターンも始まる。
そこで大切にしているのは、手元環境をいつでも正しく安定して起動すること。
docker compose いつbuildするのか問題
Renovateなどを使ってライブラリをどんどん上げている状況で、うっかり古い開発用のイメージを動かしてしまうと、ライブラリが古くて手元で正しく動かず、エラーが出たりする。
エラーが起きたらとりあえずdocker compose buildしてみてください、といって案内することもできるけど、イメージの問題なのか、その上のアプリケーションの実装の不備なのか切り分けが面倒になったりする。
また、常に最新のイメージだけを使えば良いわけでもなくて、開発中のこちらのブランチで使いたいライブラリはちょっと古い、といったこともありえるので、手でイメージを管理する気にすることが多い。
手元環境のエラーを観察するソリューションとして、過去にはこういうグッズを作ったりしていたけど、そもそも起動に失敗していたらエラーの送信までたどり着けないこともある。
ちなみに、今はこういうミドルウェアは使ってなくて、Sentryでローカル環境のエラーも送ってしまっていて、なかなか便利。
blog.sushi.money
docker composeのwrapperから正しいイメージをpullする
実行環境をあらわすタグを自動で計算して、そのタグでコンテナリポジトリからpullする仕組みを作っている。
script/docker-composeという名前のスクリプトで、docker composeコマンドのかわりに実行すると以下のようなことを自動的にやってくれる。
- イメージはAWSのECRに置いているので、まずAWSにログインする
- 現在チェックアウトされているソースコードから、Perl、Node.jsなどのコンテナごとに、使うイメージのタグを決める
- ECRからpull、もしくは存在しなければその場でbuildしてECRにpushする
- イメージの準備が整ったらdocker composeを実行
タグには実行したい環境のファイルの一部をもとにダイジェストを付与していて、Node.jsなら以下のような決め方。Dockerfileのダイジェストの先頭何文字かを取ってくるとイメージのタグに使うダイジェストを決められる。
cat Dockerfile-node | openssl sha1 | awk '{print $NF}' | cut -c1-7こうして決めたランダムっぽい文字列をタグの末尾に付与する。GigaViewerを開発していたら、GigaBiewer-node-(ここにダイジェスト)みたいな雰囲気。
PerlのイメージにはCPANモジュールも同梱しているので、Dockerfileの内容だけでなく、cpanfile.snapshotの中身もダイジェストに含める。
cat Dockerfile-perl cpanfile.snapshot | openssl sha1 | awk '{print $NF}' | cut -c1-7こうすることで、実行したいブランチが要求するライブラリが新しければ、それ用のイメージを自動的にpullしてくれるし、新しいライブラリを追加したい人は、その要求を書いてGitHubにpushしておくと、CI上からイメージがビルドされてECRにpushされるようになっている。普通に暮らしていると手元で負荷の高いビルドを待つ必要がなくなり、逆にビルドが始まったら、いつもと違うのでおかしいぞ、と気づいたりできる。
デザイナさんの環境などでよくわからないことが起きていても、とりあえずdockerを立ち上げ直してもらえば、正しいイメージが起動されていることまでは疑わずに済むので、問題の切り分けが楽になる。
いつでも同じコマンドで動くこと
リポジトリをcloneしたら、あとは基本的にscript/docker-compose upを打つだけでいつでも起動し、その後の継続的な手元環境のメンテナンスやビルドし直しなども要らない状態を維持している。
手元環境のセットアップや起動が煩雑になってくると、新メンバーの受け入れ時のサポートコストが高まったり、チームメンバーの多いチームで正しく動かない確率が上がってくると、開発環境の維持に時間を取られるようになってしまう。
エンジニア社員ならがちゃがちゃコマンドを打つのはむしろ喜びの範疇になったりするけど、学生のデザイナーアルバイトさんだと、ターミナルにもあまり馴染みのない段階でチームにジョインされて、そこからgit commitって打ったり、ただでさえ謎の多い世界に飛び込んでもらっていると思うので、なるべく簡単に、気にすることの少なく済むようにしたいと思っている。
エンジニア的には怠惰は大切な価値観で、めんどくさいことがあったときに不満を言うことは良い動きだけど、そこから離れて普通の職場のことをイメージすると、不満を言わずにやるのが美徳みたいになっている可能性もあって、エンジニアはらくらく過ごしているけどデザイナの暮らしはめんどくさいことになっている、ということがありえる。そういうところに気にかけて、エンジニア的世界観でめんどうなことを打破していく、というのもエンジニアの仕事だと思う。
この構成の問題点
Docker Desktopのダッシュボードや、VSCodeのdocker composeのプラグインなどからみると、script/docker-composeが間にはさまっていることは想定されていないので、VSCodeの便利そうなプラグインから立ち上げると、古いイメージが動いてしまったりする。
現在は正しいイメージが自動的に選ばれる方がメリットが大きいと考えているけど、VSCodeやIDEなどの既存のエコシステムに乗っかれるほうがメリットが大きい、という判断もあり得ると思う。
たとえばライブラリをアップデートする日を決めて、それ以外のタイミングではなるべく変更しないようにするとか、そういう形にできれば、定期的なdocker-compose buildのお願いをする運用とセットで、script/docker-composeは廃止できるかもしれない。
カジュアル面談しませんか
きのうもカジュアル面談しませんかって記事を書いていますが、こうして今日も書いてみています。いつネタ切れになるのか…しかしもう何年もこのチームにいるので永久にこの話題を続けられるような気もします。
blog.sushi.money
現在マンガチームでは積極採用中でして、会社説明やチーム説明、使いやすい開発環境の作り方など、カジュアル面談でディスカッションしませんか。
下記Qiita Jobsから「気になる」ボタンを押してもらっても良いですし、採用ページから応募してもらってもよいですし、Twitterの@hitode909にDMいただいてもよいです。
とくに就職活動中ではないけど、なんとなく話を聞いてみたい、くらいでも歓迎です。
jobs.qiita.com
hatenacorp.jp
