portal shit!

Day One という日記書きソフト、愛用しているのだけど今週頭に障害が発生して日本時間で 2018/05/11 の明け方まで同期ができない状態になってた。

Day One の Sync Service 死んでるの不便…。 Twitter とかへのポストを IFTTT 経由で取り込む機能も止まってる…https://t.co/gXLiispKfl

— morygonzalez (@morygonzalez) May 9, 2018

Help Guides

The Day One Help Guides are designed to help you with tutorials, tips, and documentation for the Day One journal app.

help.dayoneapp.com

ユーザーとして不便だったけど復旧にかなり時間がかかったのがソフトウェア開発者の一人として興味深かった。何が原因で復旧が遅れたのか推測した。

Day One のバックエンドは AWS に構築してあるようで、負荷でサーバーがダウンしたのなら EC2 インスタンスを追加してサーバー再起動すれば良いはずなのですぐ復旧できるはずと思ったが、一向に復旧しない。復旧作業の状況報告ページにしきりに “server rebalance” というフレーズが出てきており、アプリケーションサーバーで “rebalance” なんてことはやらないから、どうもデータベースがクラッシュしたようだった。

Day One のバックエンドエンジニアの採用情報見たら技術スタックが書いてあって、開発言語は Scala で DB は Couchbase を使ってるとのことだった。で、 Couchbase では Shared Cluster の rebalance という作業が必要らしい。

Couchbase は CAP 定理のうち一貫性と分断耐性を保証していて、その代わりに可用性が犠牲になっている（Couchbase Server - Wikipedia）。 Day One では複数のクライアントからほぼ同時に同一ドキュメントに対して更新が走ることが多いし、 iOS からは不安定なモバイル回線経由で接続される。かつては Dropbox や iCloud も同期のバックエンドとしてサポートしていたが、コンフリクトしたり意図せぬデータ欠落などがあったと思われ、自前のバックエンドシステムに移行したのだろう。一貫性と分断耐性に特化した Couchbase はユースケースとして最適に思えるが、障害が起こるとリバランスに手間取り復旧の難易度が上がるようだった。

自分は大規模分散データベースみたいなやつは受託の会社に勤めてた下っ端の頃にしか使ったことがなく、自分でがっつり運用・構築したことがないので大規模データベースに対する知識が足りていないと思う。大した考察は出来ていないが、今後もバックエンド API おじさんとして余生を過ごしていく上で参考になる出来事だった。そのうち詳細な post-mortem が Day One のエンジニアによって公開されるようなのでこちらもあとで読んでおきたい。

あまりに復旧が遅かったのでこのままサービス終了するのではないかと心配になったが、何とか復旧出来たようである。 Day One のバックエンドの皆さんおつさまでした 🍵

前書いてた記事の続き。

🏭 Docker を Production 投入するメリットを考える

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導...

portalshit.net

Kaizen Platform 時代は Naoya Ito さんの以下の記事にあるような感じで deploy してた。 Slack 上で hubot に話しかけると deploy 用の Pull Request が作られていい感じに deploy フローが始まる。

GitHub 時代のデプロイ戦略 - naoyaのはてなダイアリー

少し前までアプリケーションのデプロイと言えば capistrano などをコマンドラインから叩いてデプロイ、みたいなことをやっていたが、最近は少し様子が違うのでそのやり方、KAIZEN platform Inc. での事例を紹介する。 GitHub のイベントを契機に CI as a Service にデプロイを担当させる GitHub で Pull Request を送って開発するのが前提になっているのは以前にも紹介した。最近は Travis CI や CircleCI などに代表される CI (Continuous Integration) as a Service があって、CI も自分…

d.hatena.ne.jp

これがめっちゃ良くて、現職場でも導入したいと思ってたので今週ちょっとやってみたところ deploy できるようになった。

実際のデプロイフロー

まず Slack で hubot （ 山の会社なので tengu という名前にしてる）に話しかける。すると hubot で GitHub の API を叩いて deploy 対象の Pull Request を取得し、それぞれの Pull Request ごとに commit をグルーピングして、 deploy 対象の Pull Request の Author にメンションするかたちで master ブランチから deployment/production ブランチへの Pull Request が作成される。

最近 Slack の GitHub Integration がアップデートされて、 Webhook の通知がいい感じに飛んでくるようになったので Slack 上でどんな内容が deploy されるのかが一目瞭然となる。

実際に作成される Pull Request は以下のような感じ。この Pull Request を Merge することで CircleCI 上で deploy 用のビルドが走る。その辺は Naoya さんの記事で書いてあるのと同じ。

いま作ってるやつは AWS ECS で運用しようとしてるので、 cap deploy ではなく手製のシェルスクリプトで以下のことをやっている。

1. deploy 用のコンテナイメージをビルド
2. AWS ECR にコンテナイメージをプッシュ
3. プッシュしたイメージを利用する Task Definition を追加し、 ECS のサービスを更新 ecs-deploy というシェルスクリプトでやる

以前の記事にも書いたが「 CircleCI が落ちてたら deploy できないじゃん？」というツッコミが入ったため CircleCI が落ちていても deploy できるようにシェルスクリプト化してあるので、手元からおもむろに bin/deploy production とかやっても deploy できる。

ちなみにこのフローを実現する .circleci/config.yml は以下のような感じ。

jobs:
  deploy:
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - setup_remote_docker:
          docker_layer_caching: true
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache py-pip=9.0.0-r1 jq curl curl-dev bash
            pip install docker-compose==1.18.0 awscli==1.14.38
            curl -s https://raw.githubusercontent.com/silinternational/ecs-deploy/ac2b53cb358814ff2cdf753365cc0ea383d7b77c/ecs-deploy | tee -a /usr/bin/ecs-deploy && chmod +x /usr/bin/ecs-deploy
      - run:
          name: Execute deployment (Docker image build, push to ECR, create new Task and replace container)
          command: |
            case ${CIRCLE_BRANCH} in
              "deployment/dev" | "master" )
                DEPLOY_ENV="dev" ;;
              "deployment/production" )
                DEPLOY_ENV="production" ;;
            esac
            bin/deploy ${DEPLOY_ENV}

workflows:
  version: 2
  production-deploy:
    jobs:
      - deploy:
          filters:
            branches:
              only:
                - deployment/production

Chat deploy のよさ

deploy フロー・ deploy 状況が可視化され、民主化されることがよい。昔ながらのローカルからの capistrano による deploy の問題点は deploy の特権化を招いてしまうことだと思う。 ○×さんしか deploy 用の踏み台サーバーに ssh できないので一々○×さんに deploy をお願いしないといけない、というような状況はよく分からない遠慮や序列を招きがち。 deploy フローが自動化されていることでチームに入ったばかりの人でもさくっと deploy が行えるというメリットもある。

deploy の履歴が Slack 上と CircleCI 上、また GitHub 上に Pull Request として残るのもよい。ひとくちに deploy といっても schema 変更が伴う場合は作業ログの共有やコミュニケーションをどこかで行う必要があり、その場所として GitHub の Pull Request が使えるのがとてもよい。 YAMAP で作った deploy スクリプトではそこまでやってないが、 Kaizen Platform の deploy スクリプトには deploy 用の Pull Request 本文に動作確認用のチェックボックスを作って、チェックボックスにチェックが入れられるまで cronbot が二時間おきに deploy 対象の commit author に Slack 上で動作確認を促す、というような仕組みまであった。

今後 YAMAP でもどんどん deploy フローを改善していって Merge ボタンを押したあと寿司を食ってれば良いような状態¹にしていきたい。

ちなみに上記の chat deploy を実現するためには GitHub App を作っていろいろやる必要があって、その辺は Kaizen Platform で同僚だった t32k さんの以下の記事が参考になった。

チャットデプロイしたい2018 - MOL

タイトルの通り、チャットデプロイしたい。

t32k.me

書いてあるフローはほとんど Kaizen Platform のやつと同じでちょっとウケた。いやでもそのくらい完成されてる仕組みだと思う。この割とイケてる deploy フローを体験してみたい人は僕が勤めてる YAMAP の Wantedly をご覧下さい。資金調達しており割と積極的に採用中です。

• 株式会社ヤマップの会社情報 - Wantedly
• 山登りの地図アプリ「YAMAP」が12億円調達、業界で連携し登山者の裾野を広げる | TechCrunch Japan

今年の目標はとにかく金を貯めることにしようと思った。 いい歳なのに恥ずかしいくらい金がなくてちょっと風が吹いただけで生活が破綻しそうな予感がある。贅沢はしてないつもりだけどとにかく金がない。とりあえず三ヶ月間は給料がなくても生活していけるくらいの金は貯めたい。

💸金がない原因

車を買ってからずっとこの調子で、車を買ったことで維持費や保険料がかかるようになったことに加え、車によって行動範囲が広がったことが問題だと思う。郊外に引っ越して飲みに行く機会は減ったが、しょうもない外食をする機会が増えた。幼稚園の支払いも高い。うちは子供一人しかいないのにとにかく園納金の支払いが厳しい（年間40万円くらい）。子どもが二人以上いる普通の家庭はどうやってやりくりしているのだろう。生命保険や固定資産税の支払いも厳しい。一戸建てに引っ越したことで電気代も高くなった。郊外に家を買ってしまった以上車を手放すのは無理だし、子どもを幼稚園に通わせないわけにもいかない。電気代に関しては嫁さんが一晩中暖房をつけたまま居間でテレビを見ながら寝るのでこれをやめてもらえれば多少は改善されるだろうが、寝室で寝て欲しいと言っても「お前の頭皮と息が臭いしあたしには長谷川博己や山田裕貴が出てるドラマを見ることくらいしか楽しみがないんだよ👿」と言われるので自分ではどうすることもできない。加えて車、家、保険、教育費などもライフステージに起因する出費なのである程度はしょうがないものなのかも知れない。

💰対策

とりあえず自分に出来る範囲で以下のことをやるようにしたい。

👀保険の見直し

生命保険、親が選んだやつに惰性で入り続けてるけど明らかに損している気がする。特に医療保険は無駄がでかい気がする。解約して県民共済とかにした方がよさそう。今年分の保険料は払ってしまったので今年中にデカめの手術して保険金もらったあと解約したい。そもそも金があれば医療保険は入る必要ないと思うし金貯めて保険とか入らなくても大丈夫な状況にしたい。

🚫🍻金がかかる飲み会には参加しない

会社持ちの無料の飲み会にしか行かないことにする。二次会にも行かない。酒飲みに行ったらその時は楽しいけど飲みすぎて翌日破滅するし凄まじい勢いで金がなくなる。友達が減るのはしょうがないとあきらめるしかない。

🚫🍺第三のビールの六缶パックを買わない

家に缶ビールがあることでついつい飲んでしまう。酒がなければないでなんとかなる。どうしても飲みたいときにその日飲む一、二本だけ買うようなスタイルに改める。第三のビールとはいえ金がかかることには変わりはない。宵越の酒は持たないようにする。

🍜弁当がない日はスーパーのカップ麺で済ませる

弁当を作ってもらえなかった日の昼食代は 100 円以下に抑える。不健康になるかも知れないが早死にしたら住宅ローンがチャラになるし保険料も払わなくて済むようになるのでむしろ好都合だと思うことにする。

🚫🏪コンビニで買い物しない

前の会社は給料高い人が多くて、みんな朝の出社時に 500 円くらいするスターバックスのコーヒー、昼飯食ったあとに 300 円くらいするスターバックスのコーヒー、三時のおやつに 400 円くらいするスターバックスのコーヒーを買ってた。自分はスターバックスのコーヒーは買えなかったけど周りに流されてコンビニコーヒーを買う癖がついてしまった。セブンイレブンのコーヒーは一杯 150 円でも量が少なくて二回くらい飲みたくなってしまい一日で 300 円使ってしまうことになる。毎日買ったら月 6000 円になる。一生懸命頑張る自分へのご褒美、みたいな感じで朝から高いコーヒー飲んだりよい昼飯食ったりするという考え方もあるとは思うが、自分はそんなに仕事頑張ってないし稼ぎもよくないのでこういう思考とは距離を置くべきだと思う。ときどき朝食にコンビニで総菜パン買って食べるのもやめる。

🚫💻GitHub の有料プラン解約

なんかうぇぶさーびすを作って一発当てようと自分にハッパかけるつもりで Developer Plan に加入してるけど大したコード書いてないし人様に見せられないコードの置き場所は GitHub から Bitbucket に変える。

🚫🛒コストコに行かない

一昨年の 9 月に会員になって去年の 9 月に失効した。余裕ができたら更新したいと思っていたけどコストコ行くと 2 万とか平気で使ってしまうので貯金が目標金額に到達するまでコストコ断ちすることにする。

🙅🏻‍♂️抵抗

逆に嫁さんにやめろといわれて抵抗しているのは以下。

🖥さくらVPSの解約、もしくは下位プランへの変更

プログラマーなので自由に使える Linux サーバーがないと厳しい。このブログはファイルシステムを結構使うようにしてあるので Heroku だと多分動かない。 AWS は逆に高くなる。

いまはメモリ 2GB プランを使っているので下位プランへ契約変更するという手もあるが、いま動かしてるアプリケーション（ puma × 2）だけでも結構メモリが足りないと感じることがあるのでさらにスペックダウンするのは厳しい。実験の場を失うことで長期的には年収を下げることにもつながりかねない。

そもそもサーバー代は Google Adsense と Amazon Associate で 2/3 くらいはまかなえてるのでここは手を付けないことにする。

🎞Amazon Prime 解約

解約してしまうと 2000 円分買わないと送料無料にならないとかいろいろ厳しい。 350 円のものが欲しいだけなのに送料無料にするために 1650 円の大して必要ではない何かを買わざるを得ないシチュエーションはとてもストレスがたまる。せっかく Apple TV で見られるようになった Amazon Prime Video を見られなくなるのも残念。このくらいは死守したい。

正月早々汚らしく金の話をしてしまって最悪だけど、 @taketin さんや @kitak 、 @t32k さんなどといった元同僚の富裕層の皆さんのように用事もないのにヒルトンに泊まったり、一回買って売ったイヤフォンをもう一回買い直したり、わざと虫歯になってセラミックの歯を自慢したりできるような身分になりたい。バカすぎてブロックチェーンとかはわからないので今年は金を貯めることだけを目的にやっていきます🤑

仕事面で 2017 年を振り返ると、いろいろやったけど自分でなんか作ったというのはほとんどない。 人のふんどしで相撲をとっていた一年（転職してからは半年強）だと言える。SaaS として提供されているツールを導入したり、 OSS の分析ツールを導入・構築したり、会社の仕組みを調整したりしてただけだった。各ライブラリを作ってくれた人には感謝しかない 🙏🏻

組織方面

• チーム横断の定例 MTG 働きかけ
  • 人が増えて「あの人何やってるかわからない」「仕事を横からいきなり依頼される」などの問題が出てきたため、チーム横断の定例ミーティングを開催してお互いの状況を確認したり依頼しそうなことがあれば前もって共有するように
• 全体ミーティングフォーマット整え＆司会業
  • かつては社長が考えていることを聞くだけの場だったが、チームごとに資料を作ってみんなで発表し、議論をする場に変えた
• Slack 導入
  • Slack に変えるまでも別のチャットツール使ってたけど、平アカウントでは大したことできず、窮屈な感じがした
  • Slack は平アカウントでも外部ツール連携したり API 使ってなんかやったりできて便利
  • ベンチャーには平社員でも必要なことをやれるようなシステムの方が向いてると思う。 Slack はデザインだけじゃなくてそういうところが優れている。フラットで雰囲気が明るい。使うのが楽しくなる。
• Kibela 導入
  • Wiki と Blog 、 Board （ Group ）の概念がちょうどよい。 Qiita:Team で厳しかったところが解消されている。
  • Kibela 導入以前、情報共有は Issue Tracker に何でも書いてる感じだったが、 Issue Tracker は Issue Tracker なので close することができない問題を扱うのに向いていない
  • タスクには落とし込めないけど社内で見解を表明しておきたい事柄を社内ブログに書いて問題意識をみんなと共有する文化を構築できた
  • Kibela は PlantUML で図を書けるのがとにかくすばらしい。込み入った処理フローをシーケンス図にすることで設計・実装がはかどる。
• HRT について説く
  • きつい話し方やめましょう😇
• OKR 導入
  • OKR を設定してやっていきましょうという風にした
    • とはいえ自分は HR の専門家ではないのでちゃんと運用して行くにはそういう人に入ってもらわないと厳しいと思ってる

エンジニアリング方面

• t_wada （テスト文化根付かせ）業
  • No Test, No Merge
• CI が回る仕組み構築業
  • テストコードは別の人が書いてたけど回せてなくて fail しっ放しになってたので気合いで通るようにして CircleCI で Pull Request ごとにビルドするようにした✌🏻
• Pull Request テンプレート導入
  • どんな問題を解決する Pull Request なのか、何をやったのか、完了条件を明記する✅
• Pull Request レビューフォーマット提案
  • Must, Should, IMO などラベルを付けてレビューをするように
    • すべてのレビューに馬鹿正直に答えてたら時間がかかってしまうのでレビュー内容にも優先順位を付けてレビューする
    • pull request を利用した開発ワークフロー // Speaker Deck
• gitignore されていた Gemfile.lock をリポジトリに突っ込み業
  • Gemfile でバージョンが固定されてた😢
• Embulk で分析用データ書き出し業
• autodoc で API ドキュメント自動生成の仕組み構築
  • Google Spreadsheet による手作業更新からテストコードとビルドによって自動生成される仕組みへ（📝 CircleCI と autodoc で Rails API のドキュメントを自動更新）
• Git Flow から GitHub Flow へブランチ戦略変更
  • 1日に何回もデプロイするような製品はこっちの方が向いてる
• Rubocop 導入＆ .rubocop.yml 番人業
  • 👮🏻‍♂️
• CircleCI から勝手に deploy される仕組み導入
  • 社内確認環境には master ブランチにマージされたタイミングで勝手にデプロイされる（🏭 Docker を Production 投入するメリットを考える）
  • F/E の人に聞かれて「あ、デプロイしてませんでした🤷🏻‍♂️」がなくなる
• docker-compose 導入
  • Docker は使われてたがクラスターの管理は手運用だったので docker-compose 使うようにした
• AWS ECS 導入
  • 自分のブログで結構金かけて検証した甲斐があった（🚨 Docker & ECS 化追跡 24 時）
• 社内 Gyazo 導入
  • Gyazo る文化がなかったので
  • サーバーサイドは yuya-takeyama さんのやつをフォークして使ってる
• Redash 導入
  • 経営陣しか数値に関心を持ってなかったので全員が見るように毎朝 Slack に KPI を通知するようにした
  • 複雑なクエリを組んでテーブルごとに値を集計しているだけでは見えてこない値を追えるようになった
  • 独自に KPI/KGI を設定して Growth Hack に取り組むエンジニアも
• リードレプリカ作ってデータ分析がやりやすくなる仕組み導入
  • RDS で Multi AZ にはなっていたがリードレプリカがなく重いクエリを投げられなかった
  • 複雑な JOIN クエリも書けるようになりデータ分析し放題
  • 来年は BigQuery とかも使えるようにしてさらに分析が捗るようにしたい
• Itamae でプロビジョニング（ Linux アカウントの管理）
  • Itamae 一発で Linux アカウント追加できるようにしてサーバーサイドのエンジニアしか DB にクエリを投げられない状況を改善
• cronbot 導入
  • 他人が作ったスケジュールも更新できて便利
  • KPI 通知は redashbot と cronbot を組み合わせて実現
• iOS と Android のダウンロード数自動取得
  • iOS 側はタイムゾーンがずれる、 Android 側は更新が異常に遅いという問題があるものの、ある程度の目安となる数値が毎朝自動で Slack に通知されるように
• お問い合わせがあったときに Slack に通知する仕組み導入
  • お問い合わせはカスタマーサポートの人が一手に引き受ける感じだったけどみんなが関心を持って見るようになった
  • カスタマーサポートの人からエスカレーションされる前にエンジニアが回答
  • 不具合あったときはいち早く対応可能に
• Ruby app の前段に CloudFront 導入
  • app サーバーへのリクエストが半減
  • Nginx でキャッシュしきれてなかった静的ファイルを CloudFront でキャッシュするようになり爆速に
• サイト全面 HTTPS 化
  • CSS/JS が並列で配信されるようになり爆速に

自分でまともな OSS を作れないことにコンプレックスを感じていた時期もあったが（ OSS コミュニティでの活動が評価軸となるような職場では全然評価されない）、自分が作れなくても他の人が作ってくれるので、それをいかに組み合わせて有効活用し、価値を生み出せるかに注力すればいいかなぁと思うようになった。

もちろん、 OSS 使っててバグを見つけたり不便なところあったら改善する Pull Request なんかは出していきたいと思ってる。ただ自分は頭がよくないし、抽象的な思考は苦手で個別具体的なコードを書くことしかできないので、自分で OSS を生み出すことは諦めて個別具体的な事象に特化してやっていく方が自分的にも世の中的にも幸せだよね、という風に割り切れるようになった。

こういう割り切りができるようになったのは Kaizen Platform で仕事する機会を得たからだよなぁと思う。 OSS への考え方に限らず、コードを書く部分以外で組織を変革したりだとかオペレーションの仕組みを変えたりだとかは全部 Kaizen Platform で学んだ気がする。1年11ヶ月と短い期間だったけれど、いまの自分の血となり肉となっていると思う。

Kaizen を辞めたときの記事で以下のように書いてたけど、いまのところ失敗を糧にしていい方向に向かってるのではないかと思う。

Kaizen でのリモートワーク失敗経験をどう今後の人生に生かすか。以下のツイートを繰り返し眺めながら悔い改めていきたいと思う。

— Kaizen Platform という会社について - portal shit!

というわけでいまは YAMAP という会社で働いています。元同僚の pyama86 さんに比べたら知名度では全然負けててミジンコみたいなもんだと思うけど、そのうち逆転できるようにプロダクトの完成度を高めていって pyama86 さんの方が YAMAP のパクりであるような雰囲気を醸成していきたい。今後ともよろしくお願いいたします🙏🏻

先週、 Alfred で通貨換算をやる方法（💵 Alfred で手軽に通貨換算 💴 ）について書いたけどその続き。

Numi という Alfred に似たソフトがある。 Soulver と違い多言語対応はしておらず、自然言語による入力は日本語未対応なのだが、 Soulver もまともに使えるのは英語利用時だけなので実質的には機能に差がない。タブを使えたりする分、 Numi の方が高機能かも知れない。さらに Numi は今のところ無料である（ベータ版のため）。ベータ版とはいえほとんど困ることなく利用できている。

このソフトがすごいのが、 Alfred Workflow を入れると Numi による計算を Alfred から n <式> と入力することでできるようになるということ（ただし Numi.app を起動しておく必要あり）。こんな感じ。

いちいち Numi.app に切り替えて新規ドキュメントを作成し、ということをしなくて済む。とても手軽に計算できる。通貨換算のほかに、単位の換算もできる。 Google Fincance の Converter サービスを使うやり方よりも高機能だ。

このソフトを知ってから Soulver を使う機会がめっきり減ってしまった。 Alfred からも計算できるし、結果を残しておきたいような複雑な計算をするときは Numi.app に切り替えて使うこともできる。文章を書いたり考え事をしているときにささっと計算できて頭の切り替えコストが低い。 AWS を利用しているプログラマー諸氏なら EC2 インスタンスの料金なんかを計算するときにもとても便利だと思う。おすすめです。

この記事は Alfred 3 Advent Calendar 2017 - Adventar 12 日目の記事でした。明日は（明日も） @tsurusuke さんです。

仕事で開発中のシステムで、 master ブランチに Pull Request が Merge されると自動的に AWS ECS に構築した社内向けの確認環境にデプロイが行われるような仕組みを導入した。自動テスト、コンテナイメージのビルド、デプロイには CircleCI を利用している。 .circleci/config.yml は以下のような感じ。

version: 2

shared: &shared
  working_directory: ~/app
  docker:
    - image: xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app
      environment:
        PGHOST: 127.0.0.1
        PGUSER: user
        RAILS_ENV: test
        REDIS_HOST: localhost
    - image: circleci/postgres:9.6-alpine
      environment:
        POSTGRES_USER: user
        POSTGRES_PASSWORD: password
    - image: redis:3.2-alpine

jobs:
  build:
    <<: *shared
    steps:
      - checkout
      # Restore bundle cache
      - &restore_cache
        type: cache-restore
        key: app-{{ arch }}-{{ checksum "Gemfile.lock" }}
      # Bundle install dependencies
      - &bundle_install
        run: bundle install -j4 --path vendor/bundle
      # Store bundle cache
      - &save_cache
        type: cache-save
        key: app-{{ arch }}-{{ checksum "Gemfile.lock" }}
        paths:
            - vendor/bundle
      # Database setup
      - &db_setup
        run:
          name: Database Setup
          command: |
            bundle exec rake db:create
            bundle exec rake db:structure:load
      - type: shell
        command: bundle exec rubocop
      # Run rspec in parallel
      - type: shell
        command: |
          mkdir coverage
          COVERAGE=1 bundle exec rspec --profile 10 \
                            --format RspecJunitFormatter \
                            --out /tmp/test-results/rspec.xml \
                            --format progress \
                            $(circleci tests glob "spec/**/*_spec.rb" | circleci tests split --split-by=timings)
      # Save artifacts
      - type: store_test_results
        path: /tmp/test-results
      - type: store_artifacts
        path: coverage

  generate-doc:
    <<: *shared
    steps:
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache git openssh ca-certificates
      - checkout
      - *restore_cache
      - *bundle_install
      - *save_cache
      - *db_setup
      # Generate document
      - run:
          name: Generate API doc
          command: |
            AUTODOC=1 bundle exec rake spec:requests
      - run:
          name: Generate Schema doc
          command: |
            diff=$(git diff HEAD^ db)
            if [ -n diff ]; then
              bundle exec rake schema_doc:out > doc/schema.md
            fi
      - run:
          name: Setup GitHub
          command: |
            export USERNAME=$(git log --pretty=tformat:%an | head -1)
            export EMAIL=$(git log --pretty=tformat:%ae | head -1)
            git config --global user.email "${EMAIL}"
            git config --global user.name "${USERNAME}"
      - run:
          name: Push updated doc to GitHub
          command: |
            git add doc
            git commit --quiet -m "[ci skip] API document Update

            ${CIRCLE_BUILD_URL}"
            git push origin ${CIRCLE_BRANCH}

  deploy:
    docker:
      - image: docker:17.05.0-ce-git
    steps:
      - checkout
      - setup_remote_docker
      - run:
          name: Install dependencies
          command: |
            apk add --no-cache \
              py-pip=9.0.0-r1 jq curl curl-dev bash
            pip install \
              docker-compose==1.12.0 \
              awscli==1.11.76
            curl https://raw.githubusercontent.com/silinternational/ecs-deploy/ac2b53cb358814ff2cdf753365cc0ea383d7b77c/ecs-deploy | tee -a /usr/bin/ecs-deploy \
              && chmod +x /usr/bin/ecs-deploy
      - restore_cache:
          keys:
            - v1-{{ .Branch }}
          paths:
            - /caches/app.tar
      - run:
          name: Load Docker image layer cache
          command: |
            set +o pipefail
            docker load -i /caches/app.tar | true
      - run:
          name: Build application Docker image
          command: |
            docker build --file=docker/app/Dockerfile --cache-from=app -t organization/app .
      - run:
          name: Save Docker image layer cache
          command: |
            mkdir -p /caches
            docker save -o /caches/app.tar organization/app
      - save_cache:
          key: v1-{{ .Branch }}-{{ epoch }}
          paths:
            - /caches/app.tar
      - run:
          name: Push application Docker image to ECR
          command: |
            login="$(aws ecr get-login --region ap-northeast-1)"
            ${login}
            docker tag organiation/app:latest xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app:latest
            docker push xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app:latest
      - run:
          name: Deploy container
          command: |
            ecs-deploy \
              --region ap-northeast-1 \
              --cluster app-dev \
              --service-name puma \
              --image xxxxxxxxxxxx.dkr.ecr.ap-northeast-1.amazonaws.com/organization/app:latest \
              --timeout 300

workflows:
  version: 2
  build-and-generate-doc:
    jobs:
      - build
      - generate-doc:
          requires:
            - build
          filters:
            branches:
              only:
                - master
      - deploy:
          requires:
            - build
          filters:
            branches:
              only:
                - master

1. master ブランチに対して出された Pull Request が Merge される
2. CircleCI でテストが実行される
3. テストが成功すると CircleCI 上からデプロイが行われる
   • コンテナイメージをビルド
   • ビルドしたイメージを AWS ECR にプッシュ
   • プッシュしたイメージを利用するタスクを AWS ECS に作成
     ecs-deploy 任せ
   • 古いコンテナから新しいコンテナに LB 切り替え
     こちらも ecs-deploy にやってもらってる
4. CircleCI 上実行された Request Spec で自動生成された API ドキュメントを GitHub にプッシュ

コードが Merge されると勝手に確認環境にデプロイされるので、クライアントサイドの開発者からデプロイを頼まれて対応する必要がないし、クライアントサイドの人はいつでも最新の API ドキュメントを GitHub 上で確認できる。 API ドキュメントは手動更新ではなくテストから自動生成されるので、ドキュメントと実際の API の挙動が異なる、というありがちな問題も回避できる。

自分としては結構頑張ったつもりだったんだけど、「それ ECS でやる意味あるの？ というか Docker じゃなくて普通の EC2 インスタンスに Capistrano でデプロイするのでよくね？」というツッコミが入った。デプロイフローで CircleCI への依存度が強すぎる、イメージのビルドとデプロイに時間がかかりすぎるし、ちょっとした typo の修正のためにイメージをビルドしたりとかあり得ない、 Docker を使うにしても ECS は使わず、 EC2 で Docker を動かし、コンテナがマウントしたディレクトリに Capistrano でデプロイするべき、という意見だった。このときぐぬぬとなってしまってあまりうまく答えられなかったので考えられるメリットを書き出してみる。

確かに Docker と ECS による環境を構築するのには時間がかかる。デプロイのためにそこそこでかいイメージをビルドしてプッシュするというのも大袈裟だ。加えて Production で運用するとなるとログの収集やデータベースのマイグレーションなど、考えなければならない問題がいくつかある¹。

ただコンテナベースのデプロイには以下のようなメリットがあると思う。

環境のポータビリティー

まず Ruby や Rails などのバージョンアップが容易になる。手元で試して確認した構成とほぼほぼ同じイメージをデプロイできる。デプロイ前にサーバーに新しいバージョンの Ruby をインストールしたりしなくて済むし、手元ではエラーにならなかったのに本番でエラーになった、というようなケースを減らすことができる。

サーバー構築手順のコード化

人数が少ない会社で専業のインフラエンジニアもいない状況だと Chef や Puppet でサーバーの構成管理をし、複数台あるサーバー群の管理をすることは難しい。 Dockerfile に手順を落とし込み、 Docker さえ入ってたらあとは何も考えなくて良いというのはとても助かる。少なくとも秘伝のタレ化しやすいサーバーの構築手順がコード化され、コードレビューのプロセスに載せることができる。

迅速なスケール

AWS ECS のようなマネージドコンテナサービスと組み合わせて使えばスケールアウトが楽ちん極まりない。 AWS マネジメントコンソールか cli で操作するだけで簡単にスケールさせることができる。スケールに際して LB に組み込む前にプロビジョニングしたり最新のコードをデプロイしたりする必要もない。

デプロイ失敗が減る

Capistrano によるデプロイはデプロイ対象が増えてくると SSH が不安定になりデプロイに失敗することが増えてくる。 ECS のような AWS の仕組みに載せることで、イメージを ECR にプッシュさえできれば IaaS 側でよろしくやってくれるというのはとても良い。

以上のようなところだろうか。まだ Production に投入するところまでは持って行けてないので、今の自分の考察が正しいのかどうかをこれから検証していきたい。

関連してそうな記事

📝 CircleCI と autodoc で Rails API のドキュメントを自動更新

autodoc を導入して Rails プロジェクトで Request Spec を書くと自動的にドキュメントが更新されるようにした。 autodoc 自体は前々職の頃から利用していて大変お世話...

portalshit.net

プログラマーの種類、いろいろあると思う。

1. ハッカー
   プログラミングが楽しくて、コードさえ書ければあとは何でもいいという人。
2. OSS プログラマー
   1 と似てるけど、 OSS が楽しくてコードを書いてる人。カンファレンスで登壇したり、技術ブログを熱心に書いたりする。
3. プロダクト指向プログラマー
   開発だけでなく事業の方向性にも口を出したい人。社長が死んだらいつだって代替ができる、というような気概の人。
4. サラリーマンプログラマー
   プログラミングは仕事のためと割り切っていて、余暇には一切コードを書かない人。

1 〜 4 のどれか一つに綺麗に分類できるというものではなく、 1 かつ 3 とか、 3 かつ 4 とか、複数にまたがる人もいる。

職業プログラマーになりたての頃、サラリーマンプログラマーしかいない環境で働いて早くそこを抜け出したいと思っていた。プログラマーは会社の最下層で、プロジェクトマネージャーや営業が偉かった。プログラマーの人たちは仕事のために仕方なくプログラミングしてた。

それが嫌で余暇でもコード書くような人たちがいる職場に移ったけど、そこではハッカーや OSS プログラマーがよいプログラマーの代表とされていた（と思う）。自分もそういうのを目指し OSS カンファレンスに登壇したり技術的に中身のあるブログ記事を書いたりしたいと思ったけど、なかなかよいコードは書けないし、結婚して所帯を持つと町内会の草むしりや廃品回収、町内の運動会のテント設営、審判にかり出され、またあるときは子どもの幼稚園に夫婦そろって呼び出されて「お前らは夫婦そろって人間の屑以下だ、心を入れ替えるか幼稚園を辞めるかどっちか選べ」と説教されるなど多忙を極め、勉強会で話したりブログ記事を書いたりということが難しくなった。

一時期は自分は凡人プログラマーなんだろうなぁ、かつて忌み嫌っていたサラリーマンプログラマーと同じなのかなぁ、と将来を悲観していた。この頃は技術的な伸びしろがなくなって学ぶことに対する意欲が失せてしまっていた。

ただ、仕事で失敗プロジェクトを担当してつらい目に遭うことが多く、チームで仕事することだとか、失敗からどう学ぶかとか、その手のことに関してはそこそこ知見が貯まっていった。どうすればチーム開発はうまくいくのか、どういう風に情報を共有すればいいのかなどなど。業務改善のためにちょっとしたスクリプト書いたり、ぶっ壊れて動かなくなってる hubot スクリプトを直したり、 CI のセットアップを頑張ったりと、エンジニアチーム全体の生産性を上げるような落ち穂拾い業務みたいなタスクも好きだった。

いまは自分はチーム開発プログラマーなんだろうなぁと思う。ハッカー気質は皆無じゃないけどそこそこ、 OSS へのコントリビュートも気が向いたときに、プロダクトのことを気にする気持ちもある。どれも中途半端で単独では生産性高くないけどチームで仕事をするときに効能を発揮するタイプ。こんな風に自分が適している役割が分かると仕事がやりやすくなるし、目指すべき方向性のようなものが明確になって将来のことを考える上でも役に立つ。

ベンチャー企業で働く場合は自分のマインドやスキルセットが会社のステージにフィットすることも大事だと思う。もともとはベンチャー企業でも成功して上場しているような会社だとデプロイ時にハンコリレーなどがあってやるべきことをやるべきときにババッとやるのが難しい。そういうのは自分には向いてない。一方で起業したばかりの小さなスタートアップも、自分のような最初から綺麗なコードを書こうとするプログラマーはきっとフィットしない。起業したばかりのスタートアップでは自分たちの事業が社会から求められるかどうか不透明なので、そんな状態でテストがどうだとか CI がどうだとかチーム体制がどうだとかを言うようなプログラマーは必要ない。汚くてもクソコードでもテストコードなんて存在しなくてもいいからとにかく金を生み出すコードを素早く書ける人が向いている。

その意味でいまいる会社は創業当初の価値仮説の検証は済んでいて、これからいかに事業を伸ばしていくかというステージに入っているので、ちゃんとテストを書いたり、 CI を導入して継続的インテグレーションに努めたり、デプロイをいい感じにしたり、情報共有ツールを導入したり、開発チームの組織体制を云々したりといった部分で価値を発揮しやすい。

一握りの本当に優秀なソフトウェアエンジニアってのは受託会社だろうが事業会社だろうがベンチャーだろうが大企業だろうがどこにいたって価値を発揮できるのかもしれない。しかし自分のようなすべてにおいて中途半端なプログラマーは、自分に何ができるのかを理解し自分を必要とする規模とステージの会社を見つけてそこの門を叩くのがよいと思う。もちろん、事業に共感できるとか、チームメンバーとの相性も大事だけど、事業に共感できてもチームのメンバーがいい人ばかりでも、会社の規模やステージが自分を必要としなければ価値を発揮することは難しい。

関連してそうな記事

良いエンジニアの定義

今年は転職して働く環境が変わり、自分のエンジニアとしての能力が足りないと痛感させられることが何度もあった。しかしそれは技術力が足りないというよりも、もっとほかのもののように思えた。良いエンジニア...

portalshit.net