hitode909の日記

趣味はマリンスポーツですの日記です

社内横断で開発効率を上げる取り組み #pepabohatena

プレゼンモード
再生
← / →で移動
fでフルスクリーン
escでおわる

こんにちは,id:hitode909です.はてな・ペパボ技術大会 #4 〜DevOps〜 @京都において,「社内横断で開発効率を上げる取り組み」というお題で発表しています.この記事は,その発表資料です.

社内横断で開発効率を上げる取り組み

はてな・ペパボ技術大会 #4 〜DevOps〜 @京都
hitode909

自己紹介

オブジェクト指向入門 第2版 原則・コンセプト (IT Architect’Archive クラシックモダン・コンピューティング) オブジェクト指向入門 第2版 方法論・実践 (IT Architects' Archiveクラシックモダン・コンピューティング) エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)

  • 2009年〜 うごメモチーム
  • 2012年〜 ブログチーム
  • 2017年〜 マンガチーム
  • 2018年〜 CTO室(兼務)

アジェンダ

  • CTO室での活動
  • 特定のチームに閉じず,社内横断で開発効率を上げるための試み

みなさん

学生の方?

🙌

社会人の方?

🙌

Devの方?

🙌

Opsの方?

🙌

DevOpsの方?

🙌

DevOps

  • 開発者と運用者が協力しましょう,というムーブメント
  • 3月くらいに出た本だと,あまり技術という雰囲気でもなくなっている

Effective DevOps ―4本柱による持続可能な組織文化の育て方

コラボレーション、アフィニティ(親近感、一体感)、ツール、スケーリング

日々のDevOps

  • ふだんはあまり意識していない
  • が,ふだん考えていることと通じるものがある
    • お互い信頼して率直に話すことの大切さ
    • チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ ピクサー流 創造するちから――小さな可能性から、大きな価値を生み出す方法
  • DevOps時代にアプリケーションエンジニアが何をしていくか
    • コラボレーション先として,技術の上下のレイヤだけでなく,チームや職種という方向で横にも行けることを示したい
    • DevとOpsの話はあとでitchynyが話してくれます

CTO室

  • CTOと仲間たちの部署
  • 技術基盤的なことをやっている
  • CTO1人チーム→3月から3人→4月から4人体制
  • hitode909は開発効率を上げる取り組みをすることになった
    • 人によって活動内容は様々で,ほかの活動内容としては,データ基盤の仕組みを整えたり依存ライブラリのアップデートを支援するツールを作ったりしている

どこから手をつけるか

  • 手早く,やってる感を出すため,最小工数でできることから始めた
  • 社内誰でもペアプロできる活動

hitode909はこのたびCTO室を兼務することになりました.
兼務第一段として,hitode909がペアプロに出向く,というのをやってみます.

社内グループでの周知

社内の事情

  • プロジェクトがたくさんあり,チームごとに閉じている
  • 昔は全部Perlだったが,今は言語もバラバラ(Perl, Scala, Go, Python,...)
  • Perlではフレームワークを使わず,プロジェクトごとに手作り
    • フレームワークがあれば獲得できる共通言語も得られなかったりする
      • Railsの人はkaminariの話をできるが,共通の実装がないので,108個のページャ実装が生まれる

f:id:hitode909:20180620113658j:plain

ページャ実装マニアックス
  • ふだんの意識はチーム内に向きがちなので,外のチームとペアプロすることで,知識の媒介になれるのではと考えた
    • チーム内でのペアプロは頻繁にやっていて,知識や知見の交流などうまくいっている

ペアプロ活動

そんなにうまくいかなかった

  • 毎週できたらいいなと思ったけど,それほどではなかった
  • 分析
    • 頼みづらいのではないか
      • どうぞと言われても,チームも別だし,困ってたらチーム内でまずは話しそう
    • エンジニア向けの周知ではなく,計画を立てたりアサインを考えたりするディレクターから根回ししたほうがよかったかもしれない

次にやったこと: 物理CTO室

  • メンバーは全員兼務で,チームも分散している
  • ふだんはSlackの#ctoチャンネルで活動している
  • 毎週金曜日はCTO活動デーということにして,物理CTO室を作り,集まることにした
  • 通りすがりの人と雑談したり,相談したり
  • ブレインストーミングできるホワイトボードを設置したり
  • のぼりが目印

https://cdn-ak.f.st-hatena.com/images/fotolife/h/hitode909/20180413/20180413103219.jpg

  • Effective DevOpsにもdevopsワークスペースの話がでてくる
    • 会議室を確保して職種を問わず,DevOpsのために共同作業する

開発者、テスター、プラットフォームサポートといった人たちが何らかの取り組みのために共同作業しているのです。

課題

  • オフィスが3フロア * 2拠点にある
    • 東京から参加しにくい
    • 出張CTO室してはどうか,とか話している

並行してやっていること:開発効率を上げるグッズの開発

  • 日々の困りごとを解消するグッズを作り,社内どこでも使えるようにする,という活動をしている
  • 展開方法として低レベルなものから高レベルなものまでいろいろ試したので紹介

最初に作ったもの:コピペしてたら怒ってくれるやつ

  • ある日触ろうとしたコードがコピペされていることに気付いた
  • コピペ率を計算すると6%もあって高い
  • もともとあった継承関係をある日やめることになり,コピペで実現されていた
    • すごいコピペが起きていないか機械的にチェックしたい

コピペ率をチェックして,commit statusを更新する

  • jscpdを使って重複率をチェック
    • 各種言語に対応したコピペ率計算ツール.Node.jsで動く
  • あらかじめ指定した閾値以下ならOK,上回ったらテストを落とす
  • 導入しやすくするため,Dockerで動く形に
    • 社内のJenkinsはチームごとにインスタンスを立てている

github.com

f:id:hitode909:20180620210307p:plain

たったの3行で導入しませんか

  • Jenkinsfileに書いてもらう作戦
    stage "Checking Code Clones"
    sh "docker pull hitode909/ccchkr"
    withCredentials([[$class: 'StringBinding', credentialsId: '*********', variable: 'PERSONAL_ACCESS_TOKEN']]) {
        sh "docker run --rm --volume `pwd`:/src/:ro -e LIMIT=1 -e PERSONAL_ACCESS_TOKEN='$PERSONAL_ACCESS_TOKEN' -e COMMIT_ENDPOINT='https://github.com/api/v3/repos/hitode909/kindairb/statuses/${env.GIT_COMMIT}' hitode909/ccchkr ccchkr.sh --path lib/"
    }

これもそんなにうまくいっていない

  • コピペベース
  • docker pullしてdocker runくらいであっても,コピペして書きたくない
  • ということで使い勝手はいまいち

便利グッズ再利用のレベル

使ってもらうためにはどうすればよいか?ということを考え始めた
上が低レベル,下が高レベル

  • 口伝で真似して実装
  • デザインパターンを真似して実装
    • パタン・ランゲージ―環境設計の手引
  • 完成品をコピペ
    • よくあるコードのコピペはこの段階
  • ライブラリを導入
    • 実装言語の問題
    • 導入自体がコピペだったりする
  • どこかにデプロイされていてアプリケーションを利用開始すれば使える
    • ここを目指したい

テーマ

  • 特定のチームに閉じず,どのチームでも使えるもの
  • 開発や運用の役に立つもの
    • DevとOpsという話だけでなく,お問い合わせ対応とかにも使えると便利

裏テーマ

  • 簡単に導入できるグッズの形の模索
  • 再利用性が高い状態を目指す
    • ターミナルでコマンドを叩いて起動→敷居が高い
    • エンジニアしかアカウントを持ってない→誰でもアカウント持ってるほうがよい
    • Devエンジニアしかアカウントを持ってない→誰でもアカウント持ってるほうがよい
    • ディレクターやサポートも使えるとよりよい
    • 誰でも使えるとよい

導入する

  • まずは自分たちのチームで使って便利に使う
  • 横のチームにも宣伝していく

まずは自分たちのチームで使って便利に使う

  • ドッグフーディング
    • 闘うプログラマー[新装版]
    • ふだんの開発でも実践している

speakerdeck.com

横のチームにも広める

  • 社内のグループウェアで宣伝する
  • 昼休みとかに雑談する

次の事例:sukushokun

  • 定期的に指定したURLのスクショを撮って保存してくれる君

動機

  • アプリケーションの様子がおかしい,とくに見た目が変わった,というとき,どのタイミングからおかしかったのか判定するのがむずかしい
    • コードの不備ならgit bisectで探せる
    • 自分たちのコードを変えてなくても環境の変化で壊れたりする
      • ある日twitterボタンのデザインがリニューアルする
      • 想定外のコンテンツが入って壊れる
      • 問い合わせをもらった時点ではおかしかったが,もう直っている

動機(2)

  • URLがあれば撮影できるので,簡単に導入できるツールの例として,練習にちょうどよいと考えた

自動的にスクショを撮る

  • puppeteerを使うと便利
  • Google製の,Google ChromeをNode.jsから呼び出せるやつ

github.com

const puppeteer = require('puppeteer');

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();
  await page.goto('https://example.com');
  await page.screenshot({path: 'example.png'});

  await browser.close();
})();
  • ほかのブラウザでも動かしたい,となったら別のアプローチが必要
    • Seleniumとか使うことになるが,動作が安定せず苦手意識がある

さかのぼって見たい

  • 定期的にスクショを撮り続ける
  • PC/スマホのPNGと,PDFをどこかに保存して,ブラウザから見えるようにする
    • PNGはデザイン崩れなどの確認,PDFはリンク先の確認に便利
    • PC スマホ PDFの様子
    • JPEGとかにすると圧縮されて色が変わってしまう→あとで差分を見るときにノイズがあると難易度が上がる
  • 実装をいろいろ変えていったので,初代から五代目まで

sukushokun

  • 最初の実装
  • チームのJenkinsで動いている
  • puppeteerをDocker内で動かす
  • 結果はJenkinsの成果物として保存

課題

  • メモリを使い切ったり,CPUが100%になったまま帰ってこなくなり,Jenkinsのサーバーごと死んでしまう
    • PDFを保存する処理が重く,運悪く同じタイミングに同時に動くとつらい

sukushokun2

  • kaerukun(pastak作のpuppeteer用のタスクランナー)を使って実装
    • タイムアウト処理や,並列実行数を制限する実装などが丁寧
    • kaerukunはもともとE2Eテストで使ってたのでうまくいった

github.com

課題

  • チームのJenkinsに置いているので他チームに広めにくい
    • コピペチェッカーの反省があるので,またしてもJenkinsfileをコピペしてもらうわけにはいかない
  • キャプチャを撮るURLはJenkinsで設定するので,エンジニア以外触りにくい
    • 誤ってコードのテストやデプロイ用のプロジェクトを触ってしまうと開発が止まる

sukushokun3


課題

  • 開発しづらいと力尽きてしまう

sukushokun4

  • 使い慣れたHerokuにデプロイすることにした
  • 安定して動く,誰でも使える版
  • Google Driveに,名前=URLのフォルダを作るだけで利用可能
    • 撮影用のフォルダにsukushokunのService Accountを招待している
    • エンジニアじゃなくても使え,フォルダにファイルが入っていくので直感的

f:id:hitode909:20180620212846p:plain

課題

  • 一週間後にGoogle Driveの容量を使い切って引退
    • 追記: 当日の発表において,GoogleのCloud Storageを使うとよいのでは?とアドバイスいただきました.Google Driveは使い慣れたストレージだったので,飛び付いていましたが,冷静に検討するとCoud Storageを使えば解決していたかもしれません

雑談:Heroku便利

  • Deploy to Herokuボタンが便利
  • configは環境変数に切り出さざるを得ない

github.com

sukushokun5

  • ストレージがネックだったので,Amazon S3に置くことにした
    • 容量制限がなく,自動的に古いオブジェクトを消す設定があるのが便利
    • S3に置くだけではAWSのアカウントがないと見れないので,s3-bucket-listingを使って素朴なビューワも用意
  • SpreadsheetにURLを書いていく
  • A列のページ名がフォルダに対応

f:id:hitode909:20180620213046p:plain

課題

  • デプロイするためにはAWS,Google,Herokuが登場し,トライアスロンっぽい
  • とはいえ安定して動いているので今はこれを動かしている

github.com

sukushokun活用事例

  • パフォーマンスが劣化したときに,付近のスクショの変化を見て原因を解明
    • スクショがあればDevとOpsで協力できる
  • 画像の色の感じが変わったというお問い合わせがあったときに,いつから変わったか調査
    • 同時期に画像を動的にリサイズして配信するようにしたので,その影響かどうかを調べた
    • スクショがあればエンジニアとサポート担当で協力できる

今後

横展開のしやすく作るコツ

  • サービスの性質を問わず発生するオペレーションを支援する
    • スクショはどのサービスでも撮れる
    • 時系列をさかのぼった調査は,どんなサービスでも発生する
    • (スマホアプリやJSONなどのAPIは非対応)
  • 疎結合に作る
    • コピペチェックするにはコードを見る必要がある
    • URLのみに依存すれば,結合が疎になる
    • URLがあり,HTTPでやりとりできればなんでも使える
  • 最初からGitHubに置いておく
    • 社内に置くと横着して秘密の情報とか書いてしまいがち
  • コードは公開し,外部にデプロイできるようにしておく
    • 家庭や趣味でも使える
      • 趣味で運用しているサービスのスクショもこれで撮っています
    • 社内限定のリソースにどうやってアクセスするかは課題

まとめ

  • CTO室でのここ数ヶ月分の活動を紹介しました
  • コードを書くことよりは,問題を解決するために自分で動いていくほうが大事
    • ペアプロできるのでやりたかったらどうぞ,という姿勢ではなくて,困ってることないですかって社内を徘徊するとか
    • コードを書けば解決ではなく,便利さを伝えたり宣伝したりする必要がある
  • コードを書いて解決できる問題であっても,作り方によって解決しないことがある
    • 導入障壁が高いグッズは使いにくい
  • DevOpsはDevとOpsにとどまらず,人間が二人いるときの関係,「人と人」くらいの意味になってきている

  • 一緒に開発効率をアップするメンバーを募集しています

hatenacorp.jp

宣伝

キラキラシール配ってます

https://www.instagram.com/p/BV42S2alA86/media/?size=l