Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a 「自動化...か、かっこいいタル」（憧れ）から始める自動化
Semelhante a 「自動化...か、かっこいいタル」（憧れ）から始める自動化 (20)
「自動化...か、かっこいいタル」（憧れ）から始める自動化
- 1. 「自動化...か、かっこいいタル」 （憧れ）から始める自動化 株式会社 MonotaRO 沓 洋和 (id: hirokts) ECサービスフロントエンドエンジニアが リリース改善やブラウザ自動テストに取り組んでみた話
- 2. 自己紹介 沓 洋和 （Hirokazu Kutsu） 株式会社MonotaRO Pyton/JavaScriptによるWebアプリ開発 コミュニティ活動 DevLove関西 スタッフ 12月にあったDevLove現場甲子園西日本大会では会場の司会などをさせていた だきました。 そのほか はてなブログ、Twitter(については作っただけ): hirokts 趣味で「はてブ」やってる者、だけな感がぬぐえない Final Fantasy 11 (オンラインRPG) やっています。 ぎゃっだう FF11の種族 タルタル 語尾に「～タル」を付けるのがルール。 「か、かっこいいタル～」
- 3. MonotaROとそのIT部門紹介 MonotaROとは 「工具」「オフィス用品」など、企業向けに「間接資材」を小売りするB2BのECサービス IT部門 Web系 ECAPグループ：商品ページや登録・購入処理などのWebアプリケーション開発 コンテンツ開発グループ：サイト内検索やSEO, UX改善などを担当するグループ。自分はここ WEB-APIグループ 基幹系 社内業務や、商品情報の管理などの基幹業務についてのアプリケーション開発
- 4. 話す内容 「なぜ自動化？ 」というWhyの話 初心者が感じる問題意識の話 リリース改善プロジェクトがたちあがった話 実際にやった３つの改善の話 リリース改善、リリース改善のFabric化、ブラウザ自動テスト まとめ
- 6. Why 自動化? of 憧れ 世の中 自動化に関するいろんな情報があふれている DevOps 継続的インテグレーション/デリバリー Infrastructure As Code blue green deployment Immutable Infrastructure ヌーラボさんとかのスライドとかを見る 「自動化… か、かっこいいタル～」という憧れ
- 7. Why 自動化? of 現実 リリースプロセスの問題 WinSCPやSambaなどでファイルを手動コピー js/css/htmlなどの静的なファイル デザイナーさんのデプロイと管理の線引きがあいまい グループごとによってデプロイ方法が違う グループによってはApacheの動作するサーバに個別ログインが必要 デプロイ自体はシェルスクリプト
- 8. Why 自動化? of 現実 手動ブラウザテストの問題 リリースの都度同じブラウザテ スト トップページ表示 検索 商品ページ カートイン 注文確定
- 11. とりあえず、やりたいと言ってみた 自グループの振り返り(KPT)で リリースの自動化ができていないのは問題 リリースのスクリプトを読んで、問題となっている個所とかをリストアップ 改善してみたい！ と言ってみる
- 13. リリース改善プロジェクト始動！ただし… コストはかけれない アーキテクチャをよく知っているマネージャクラスのエンジニア → × インフラエンジニアが常にかかわる → ×
- 14. コストかけずに自動化って「どんな判断？」 かと個人的には思いましたが、逆にチャンス メンバーは以下のような感じ 「自動化やりたいー」と常日頃発言していたおかげでプロジェクトに参画できた ECAP(もう一つのWebフロント系)グループのフロントエンドエンジニアがあと１名 基幹業務系の割と新人に近いエンジニア １名 計３名 ＋ 自動化コーチ (GuildWorks社) の4名 2015年5月ごろから始動
- 15. チームビルディング ドラッカー風エクササイズとか、インセプションデッキとか たぶん最初はその重要性もわかってなかった…… チーム名は『オートマタ』 元ネタはロマサガ２の自動人形コッペリアからの連想 本当はシャドウサーバントにしたかった 稼働は週１日 + α 別グループの人と一緒に継続プロジェクトをやるのは初めて。会話もたどたどしい 「いいからチームランチだ！」 出典：スラムダンク 赤木の「いいからテーピングだ！」(無理がある…)
- 16. 最初の改善 初めに改善に入ったのは僕の所属グループ（コンテンツ開発グループ） 検索系の機能のWebアプリリリースと JS/ CSS /htmlの静的コンテンツのリ リースが必要 静的コンテンツは、コンテンツ開発グループでGit管理している分だけでなく、 別グループからの依頼もあったりする
- 17. これ(現状)をな…… コンテンツ開発グループでは、手作業のコ ピーが多い JavaScriptなどの静的コンテンツ WinSCPやSambaでファイルをアップロード Winmergeでの差分確認 Git (Bitbucket) 使っているのにもかかわらず…… Pythonアプリケーション Zipアーカイブ + scp + 展開 + rsync 展開とrsyncはシェルスクリプト 手動コピー まごころ感
- 18. こうじゃ！ git checkout + git pull + rsync （ただしシェルスクリプト）
- 19. 最初のリリース改善の課題 デザイナーさんのリリースとバッティングしないようにしないといけない CSSやhtml単品はグレーゾーン git diff –name-statusして、変化のあったものだけをrsyncのincludeファイ ルに含めるという苦肉の策 もちろん前提条件として、ファイルごとの管理の線引きが必要
- 20. 最初のリリース改善の課題 シェルスクリプトがわからない いや、がんばればわかるんだけど、コード修正しても他の人になかなかレビューしてもらえない 結構間違いやすく、リリーススクリプトのリリースでのミスが頻発 ミスでへこむ 「サービス開発」のエンジニアリングが本当の仕事 なのに、本題であるサービスのリリースにも影響してしまった 周りの理解を得られない・心配される 突っ走ってしまった感
- 22. Fabricってなんぞ？ Python製のデプロイなどのオーケストレーション処理のツール Python2.5以降に対応。ただし３系は使えない RubyでいうところのCapistrano シェルスクリプトでできることがほぼできるPythonラッパーみたいなもの Pythonなので文字列の処理が簡単 シェルスクリプトだと、${var##*/} とか、すぐわからなくなる Pythonなので、レビューしてもらいやすい MonotaROは基本Pythonです。 Fabric化で目指すのは「意識の低い自動化」 出典： http://www.slideshare.net/greenasparagus/ss-42424543
- 23. 周りの理解を得よう（勉強会） Fabricについての勉強会 IT部門の部門長（CTO）を巻き込んだ 「Fabricいいね」とのお墨付き ただしCapistranoのほうが好きそうだった。（前職で使ってたらしい） そのほか、改善に興味がある人が来てくれて、アーリーアダプターになってくれそうな人 がわかった インフラエンジニアの人も来てくれた。 「インフラでこういうの必要になりますねー」とのアドバイス 勉強会を開くことは、技術の紹介だけでなく周りの理解を得るために重要！
- 24. 第２の改善 ECAPグループのリリーススクリプト 商品ページや登録・購入処理などのWebアプリケーション このグループではサーバーに個別にログインが必要だった リリースの準備に時間がかかり、属人性高い デザイナーさんの業務フローの改善とjs/CSS/htmlのGit管理化 手動コピー主体 複雑で自動化されている部分が少ない Jenkinsなどとも合わせて自動化したい
- 26. というだけのはずもなく
- 27. 第２の改善やってみた結果 よかったこと WebアプリのリリースのFabric化自体はうまくいった！ Fabric用の専用サーバーを用意したことで、サーバ個別ログイン不要に アーリーアダプターにFabricスクリプトの改善引き継ぎ
- 28. 第２の改善やってみた結果 課題 デザイナーさんの業務フローの改善とjs/CSS/htmlのGit管理化 Fabricでデザイナーさん用のデプロイコードは書いた デザイナーさんの業務フローはかなりめんどいことが分かり、リプレースがうまく いかなかった……. 現在の業務フローをストレスなく移行するという面で、インフラまわりの課題が 解決できず Jenkinsを併用して改善する準備をしていたけど、活かせていない
- 30. Why ブラウザテスト自動化？ リリース時に毎回同じテストを手動でやっている トップページ表示 検索 商品ページ カートイン 注文確定 自動化したい！
- 31. Why ブラウザテスト自動化？（裏） とある新規重大プロジェクト 他案件を止めてでも進める必要がある オートマタプロジェクトも止めることが検討された とても悲しいことに、オートマタチームのM君がそのプロジェクトに引き抜かれた 新人にちかい、基幹業務系のエンジニアです ショックで意気消沈でした オートマタチームとしてもこのプロジェクトになんとか貢献しておきたい じゃないと「何やってるんだ、この一大事に」となりそう
- 32. 新プロジェクトのヒアリング 新プロジェクトでオートマタチームとして役立てることはないかヒアリング リリースの改善 開発環境のデプロイとか 「必要ない」（ほんとか？） テストの自動化 ちょっと興味ありそう
- 33. 新プロジェクトヒアリングでわかったこと 大規模なサービス開発なのにテスト計画自体が、ほとんど練られていない 技術的には結構難しい処理が追加されるらしい しかもビッグバンリリース テスト段階で火を噴くことが予想される 自動テストなどを用意したほうがよさそう
- 34. ブラウザ自動テストを早めることに （´-`）.｡oO（もともとやりたかったし） 目標 リリースの都度手動で実行している、リグレッションテストを自動化する その結果として、来るべき新プロジェクトのテストに備える
- 36. Gebとは Gebとは groovy言語によるSeleniumラッパーライブラリです。 Selenium(Selenium WebDriver)とは、ブラウザの拡張機能やOS のネイティブ機能などを利用してブラウザを操作する仕組みで す。 Pythonでも実装することができますが、今回groovyを使用 している理由はGebのラッパーライブラリが非常に使いや すいためこちらを使っています。 Gebの提供するナビゲーターAPI(Navigator API)がjQueryの ような操作を実現しているため、JQueryのセレクタに習熟 している方であれば簡単にテストを記述できます。 groovyとは JVM(Java Virtual Machine)上で動く言語ですが、Pythonなど と変わらないレベルで簡単に記述できます。 実際ほとんど何も覚えなくてもかけました。 jQueryっぽい クリック操作を functionに
- 37. Spockとは Spockとは Groovyで動作する、テスティングフレームワーク。 以下より引用 http://qiita.com/euno7/items/1e834d3d58da3e659f92 PowerAssertによる強力なレポーティング (Groovy本体の PowerAssertともまた違うらしい) DSLを使った簡潔で分かりやすい記述 単純明快なデータドリブンテストの記述が可能 標準でMockのAPIを提供 プラグイン利用でわかりやすいテスト結果 のレポートもHTMLで作ってくれます。 “when”,“then” の繰り返しで テスト記述 “given” (最初だけ)
- 39. Selenium 動作デモ
- 40. Geb + Spockについても勉強会やってみた どこのグループでもブラウザの自動テストはやりたいということが分かった なかでも、今すぐにやってほしいというオファーを出してくれるグループがあった。 オートマタチーム必要とされている感！
- 41. 新プロジェクトの開発フェーズが進む中で APIのロジックのテストが一番重要 かつ、一番人海戦術などでは対応しにくいことがわかった APIのレスポンスパターンは兆のオーダーになる可能性 修正や、リファクタリングしたときの正しさをチェックする必要がある APIの自動テストが必要だ！！！
- 42. APIのテストの自動化 インターフェース仕様通りのjsonを返すことをチェックするのにspockを使う レポートの見やすさはお墨付きなので、Spockのノウハウが活かせた 自動テストのために、Jenkinsを用意し、spockのはきだすレポートhtmlをHipchat上に通 知 HTML Publisherプラグイン 第２の改善のときのJenkinsの仕組みがここで活きた！ APIの改修がスムーズにいったらしい！
- 43. コンボがつながる オートマタチームのM君がそのプロジェクトに引き抜かれた 意気消沈する出来事だった だがしかし M君のおかげでAPIの自動テストがうまくいった。 自動化コーチ含めオートマタチームと連携できた jenkinsの設定などは、M君がやっています 第２の改善でトライしていたことがつながった Jmeterでのパフォーマンステストなどもサポートできた
- 44. あれ、ブラウザ自動テストは？ 割と順調です。 用意していたブラウザテスト自動化自体は、通常のリリースフローに組み入れると いう流れ 勉強会で「ぜひやってほしい」とオファーしたグループの自動テストを進行中
- 45. メンバーの動きで変わってきたこと 積極的に勉強会やカンファレンスに参加するようになった DevLove 東日本のにも参加してみました （現場甲子園） システムテスト自動化カンファレンス （もう一人自動化のメンバーYさん） Re:invent （M君) Seasar Confference Asiyan Autmation Allience 問題解決のために、手段をえらばないようになってきた まだまだ、だけど 必要なコミュニケーションを積極的にとる そのほか、週１でオートマタチームの進捗をマネージャー陣に対して、スタンドアップミー ティングをするようになりました。 タスクボードの前で！
- 46. まだまだ課題だな、と感じていること 他のプロジェクトにいろいろと引っ張られたときに、継続してチームと しての約束事を果たしていくこと むずかしい….. インフラの知識がまだまだ乏しい やっぱりアプリチームとインフラチームにはまだまだ壁があるんじゃな いかと思う…… 実は、 2/5 （金）のDevLove関西 『 「インフラエンジニア の現場における仕事と文化」のDiff』ではその課題の解決の 大いなるヒントが得られます！
- 47. 今後について 他のグループでやっているブラウザテストを自動化 デザイナーチームのリリースプロセスの改善 Dockerを利用した本番/開発環境の改善 Blue/greenやimmutableを目指して これについてはアプリチームとインフラチームとの架け橋を作るという意味 でもぜひいろいろやりたい その他Jenkinsを利用した自動テストの拡充
- 48. 問題振り返り 初心者が自動化に踏み出せないという意識 一つは「言ってみる」というのが大事 アジャイルコーチが提案してくれた、という運があったから解決できた？ けどその内容って再現できないのか？というとそうでもなさそう 実際にプロに提案してもらってもいいし、こういう勉強会で直接的で具体的なア ドバイスをしてくれる知り合いを増やしてもいいと思う その人をこっそりコーチ認定ですね ・・・・・・というのにこの８カ月くらいで気づきました。
- 50. まとめ サービス開発のフロントエンジニアだけじゃできないので背中を押してくれる人が欲しい 自動化コーチ コミュニティや勉強会 周りの理解を得よう 勉強会や、タスクボード＋スタンドアップミーティングの活用はいいプラクティス アプリ開発チーム・インフラチームからのサポートあってこそ 少しずつ改善が基本 「歩くようなはやさで」 でも、加速だけは続けること
Notas do Editor
- もうちょっとなんとかしたい
- もうちょっとなんとかしたい
- https://www.youtube.com/watch?v=-dZ2PLHwLI8