Wait! Exclusive 60 day trial to the world's largest digital library.
The SlideShare family just got bigger. You now have unlimited* access to books, audiobooks, magazines, and more from Scribd.
Cancel anytime.よくある業務開発の自動化事情 #jjug_ccc #ccc_cd3
- 1. よくある業務開発の 自動化事情 @irof 2015/11/28 - JJUG CCC 2015 Fall #ccc_cd3
- 2. irof ふつうのプログラマ 関西Javaエンジニアの会（関ジャバ）の人
- 3. 自動化は好きですか？
- 4. 好きかはさておき 興味はあるハズ
- 5. 困ったことがあるハズ ない人はしらん（ごめん
- 6. 自動化は話しづらい 自動化は範囲が広すぎる 広いままでもできなくはないけど 例: AAA(A* Automation Alliance) 分野が違うとふーんで終わっちゃう キレイな事例紹介になりがち
- 7. なので絞る
- 8. このセッションで言う “よくある業務開発” コンテキストを共有します
- 9. Java JJUGだしね
- 10. Webアプリケーション
- 11. 受託開発
- 12. 10人程度
- 13. スキルばらばら
- 14. 会社もばr（ry
- 15. “よくある業務開発” JavaなWebアプリケーションの受託開発 チームは10人程度 スキルはバラバラ 開発フェーズにおける自動化
- 16. そんな現場での 自動化について話します 複数の現場の話を混ぜて
- 17. ゴール設定
- 18. この話の背景 よく聞く事例紹介はキレイすぎる もっと泥臭くて生々しいハズ 現実の試行錯誤を聞きたい けれど、言いにくいとも思う だから、話してみることにした
- 19. 私が今日どこかで 自動化の苦労話を聞く お願いします
- 20. <<3分クッキング>> 自動化の知識や知見が存在しない現場での導 入パターン 手軽で有効で派手な自動化ネタを用意してお き、紹介と同時にデモを行う 想像で話すより実物を体感してもらう 「自動化は手軽」と誤解されないように！ この背景は幕間です。無視してOKです。 関西検証コレクションの「テスト自動化パターン言語プロジェクト」より。 全体は http://kencolle.github.io/AutomationPatternLanguage/ で公開してます。
- 21. 自動化の目的
- 22. パターンA 現在、心を込めて手作業しているものを 自動化する 機械に同じものを作ってもらって とっとと帰っる。帰って遊ぶ。
- 23. パターンB 現在、手でやるのは難しいことを 自動化することで可能にし 非効率な作業の代替とすることで とっとと帰っる。帰って寝る。
- 24. 自動化の目的は 早く帰ること！ ※個人の見解です
- 25. 自動化対象は すべての活動 早く帰るために なりふりかまってられない
- 26. 「Javaな開発の自動化」 でもまだ広すぎる！
- 27. なので適当に挙げる 構成管理 コーディング テスト ビルド CI 環境構築 こいつらの自動化について
- 28. <<ビッグバン自動化>> 一気に全部まとめて自動化しようとする トップダウンだとなりがち 自動化の構築難度はけっこう高い 不具合があった時、プロダクトの問題なの か、自動化システムの問題なのかがわかり づらくなる 余計なものまで自動化してしまう システムの8割は使われないとかいうアレ
- 29. 自動化の事情
- 30. テンプレート説明 まず 解決したい課題を話します 次に それっぽい解決案を話します 最後に 「そうは言っても……」な現実を話します
- 31. case 環境構築:
- 32. 環境構築 開発環境 IDE JDK ビルドツール APServer DBServer Office … 検証環境 JDK APServer DBServer 各種設定 本番環境 JDK APServer DBServer 各種設定
- 33. 環境構築-課題(1/2) 開発環境の構築は手順書に従って行う たまに手順書すらない 構築に数日かかったりする 端末の変更や新規メンバーの受け入れ時に 発生する コストが読みづらい
- 34. 環境構築-課題(2/2) 複数バージョンの検証環境を動作させたい 検証環境のリソースが取り合いであり、自動 テスト環境も競合している 本番環境と検証環境に差異がある
- 35. 環境構築-解決 プロビジョニングツール 環境構築をスクリプト化する 複数環境の高速構築や再現が可能 仮想化技術/コンテナ技術 （プロビジョニングに含まれるらしいが） ハードがなくても専用環境が作成できる
- 36. 使ってみた話
- 37. 動機 検証環境を気をつけて扱う必要があった 変更が声かけ運用 人数に比例してつらくなる よくわからない秘伝のタレ設定 本番との差異で死ぬ テストユーザーにroot/DBA権限ついてたり
- 38. 使ってみたところ クリーンすぎて困った 既存のデータで確認できない 他のデータがあるときに落ちる、なんての が拾えない可能性が出てくる テストの手を抜いている証拠だけど、そ れで賄ってる現実もある Windowsのせいで苦労マシマシ 32bitだとインストールすら…
- 39. 環境構築-現実 手順書ベースの環境構築やそれに掛かるコス トが当たり前になっている 回数の少ないイベント扱い 自動化の優先順位が低い 一プロジェクトだとコスト重い そのうち状況は変わる（願望
- 40. 環境構築-現実 仮想サーバーなどは端末のマシンスペックが厳し かったりする プロビジョニングツールは足音だけ聞こえる 組織の壁 検証環境と本番環境で管轄が違う ツールの全面適用が厳しい 経験が積めなくて実績が挙げられなくて 壁を崩せない break;
- 41. case 構成管理:
- 42. 構成管理-前提 構成管理における課題であるバージョニング と変更の追跡は、Java以前からバージョン管 理ツール(VCS)が解決している 昔はファイルサーバーで扱って、こんがら がったりしてた ソフトウェア構成管理（SCM）だと広がりすぎるので ソースコードとライブラリに限定します
- 43. VCSは使うよね svnでもgitでもいいけど Javaで使ってない現場にあったことはない 資産管理とかがファイルサーバーはままある
- 44. VCSの変遷 cvs→svnはいつの間にか変わってた感ある svn→gitは気合がいるっぽい でも流れは結構強い git採用してるところも増えてる
- 45. git未経験の方は 「git使ったことないです！」って人 どうせsvnでもたいしたことしてない 逆に1ヶ月もあれば遜色なく使える
- 46. 構成管理-課題 複数人の同時開発でコンフリクトが発生する 予期しない上書きによってデグレが起こっ たりしているのは避けたい 結果、同じファイルの編集をしないように ロック的な運用をしている 内部で作成したライブラリの管理が未定義
- 47. 構成管理-解決 DVCSを使用した上で、プロダクトにあったブ ランチ戦略をとる コンフリクトもコミットから修正可能 Gerritなどを導入して検証済みマージを行う ライブラリはリポジトリ管理ツールを使う
- 48. リポジトリ管理ツール NexusとかArtifactoryとか 内部ライブラリがあるなら使う centralとかに置けないからね インハウスリポジトリと言ったりも
- 49. 構成管理-現実 「コミットしちゃいけないファイル」のある 運用に慣れている人が多い ローカル用の設定変更とかね…… どのファイルをコミットするか選択してから コミットする（よく見ますよね？ 差分があるのに違和感ない なのでコミット漏れとかなくならない
- 50. 構成管理-現実 gitのcommit/push/pullとかはできる branch操作もそんな問題なく GUI(IDE)での操作のせいかトラブルに弱い コンフリクトは手作業マージ、たまに事故 これは変わってない
- 51. 構成管理-現実 リポジトリ管理ツールは“わかってる人”だ けが触るものになりがち Mavenのバージョニングを知らない人も多い リリースバージョンを上書きしたり “-SNAPSHOT”知らなかったり あまり機会ないから仕方ないのかなと思っ たりもしなくはない break;
- 52. case ビルド:
- 53. ビルド ここでやる あらゆること
- 54. ところで手動ビルド？ コンパイラも自動ビルドツール だからこれも自動ビルド でも手動の部分も多い 自動化は手動の部分を減らすこと javac Hello.java
- 55. ビルド-前提 javac/jarによるコンパイル/パッケージング の自動化は早期にantが解決していた ビルドツールを使わないことなんてない ゆえに一番無意識に使われている自動化かも
- 56. ビルド-課題 ビルド時に行いたいことはコンパイルとパッ ケージングだけではない 他にも同時にしたいことが色々ある 依存ライブラリを管理したい もうjar-hellはこりごりだ
- 57. ビルド-解決 プラグインやタスクの追加ができるようになっ ているので、それで解決できる Gradleかなり柔軟だしオススメ 依存解決はMavenだとdependencyManagementと かである程度は制御できる
- 58. ビルド-現実 ビルドツールは使いこなされていない IDEに読み込ませて依存解決する程度 依存階層の出し方とか意外と知らない pom.xmlとかは特定の人しか触らない その人がやりすぎて妙に複雑になっている （私のことだ！） 経験を積みにくいので、知らないのもある程 度は仕方ないのかも break;
- 59. case CI:
- 60. 継続的インテグレーション CI テスト ビルド 環境構築 構成管理 色々する 色々使って
- 61. 自動化の執事さん 自動化といえばこれ！ ってイメージもあるのでは Jenkinsのほかも最近よく聞く 自動ビルドツールを使って自動テストを実行 して、デプロイメントパイプライン通してワ ンクリックデプロイ云々
- 62. CI-課題 自動化された構成管理システムやビルドツー ル、テストなどと強調して継続的統合を行い たい 昔はライブラリアンとかが手動で行ってお り、属人化の代表でもあった ワンクリックデプロイを実現したい
- 63. CI-解決 CIサーバーは市民権を得ている感じ 昔からあるビルドサーバーだけど プラグインは豊富にあり、他の自動化システ ムと協調も容易 シェルスクリプトなどにしておけば誰でも何 をしているのかわかる 属人性を排除できる
- 64. CI-現実 属人性の排除はできていない 何でもかんでもCI職人に集中する 一方でスクリプトなら読むって人も居る プラグインは数年のうちに情報ノイズが増え たり、動作しなくなったりしている ワンクリックデプロイは環境の壁がやっぱき つい break;
- 65. case コーディング:
- 66. 設計書から自動生成だ！ 気持ちはわからないではない 設計書のまま実装するのが正ならね？ Javaは冗長とか言われてた でも *.java を生成するくらいなら低級言 語使ったほうがよくない？ 一昔前は必要だったね XML地獄とかも
- 67. *.javaの生成って…… Javaファイルの生成は積極的に避けるべき するにしてもclass/jarを生成してジェネ レーションギャップパターン できない？そもそもを見直そう 画一的な雛形のようなコードを生成したくな るのはフレームワークの力不足 イマドキは雛形の内側だけ書けばよい 役目を終えた過渡期の技術感ある
- 68. IDEによる自動記述 IDEのコード生成もコーディング自動化 単なるクラス名補完機や自動インポートエディ タではありません 使うフレームワークや作るアプリケーション によってカスタマイズしてみてもよい 思ってる以上に世界変わるよ タイピング速度を上げるよりお手軽
- 69. IDEを使い倒そう 冗長と言われるコードのほとんどがIDEを使え ば一瞬で書けてしまう 「Javaは冗長だから実装に時間がかかる」は 「Javaできません」に近い JavaのコーディングはIDEなしで語れない そういう言語なので受け入れよう
- 70. コーディング-課題 大量のコードを作成する必要があり 大量の設定ファイルを作成する必要があり 品質は均一化しなければならない ……まあお仕事でよくある話。
- 71. コーディング-解決 パワフルなフレームワークを使用することで 一昔前より大幅に実装量を削減できる Javaの表現力も向上しているし、Scalaや GroovyなどのJVM言語を選択してもよい IDEの支援を適切に受けられればタイプ量はす ごく少なく済ませられる Pluggable Annotation Processingなどでコ ンパイル時の生成が可能
- 72. コーディング-現実 昔に作られたソースコード自動生成ツールや、 その焼き直しが大事に使われている 「昔やったこととまるっきり同じこと」に 安定と安心を求めたり 完全上位互換でなければNGになったり IDEの機能はあまり使われていない せいぜいクラス名の補完くらい 妙にデバッガは使われてるけど break;
- 73. case テスト:
- 74. “自動テスト”は よく話題にあがる
- 75. 今回は あまり踏み込まない 踏み込めないが正しい
- 76. システムテスト自動化カンファレンス ってのが2015/12/13に……もう満席だけど
- 77. jUnitなテスト 見かけることは増えてきた 影も形もないってのは稀な感じ でもイマイチ上手くいってなさげ
- 78. ここにも自動生成の闇 自動生成されたjUnitのコードを稀によく見る たぶんExcelマクロとかで メンテ不可 何してるかわからない 再生成の方法も失われてたりする 無駄に量は多い
- 79. 自動生成は嫌い Parameterizedとかでカバーできる 一覧性を気にするならSpockとかあるよ Excelが見やすければ直接読み込めばよい 妙な外部DSL（Excelね）をコンパイルしてJava コード吐くとか、何したいの？
- 80. 最近の話題 そいやjUnit5の声も聞こえてきました 未評価なのでなんとも言えないけど @Test @Name("My 1st JUnit 5 test! 😎") void myFirstTest(@TestName String testName) { assertEquals(2, 1 + 1, "1 + 1 should equal 2"); assertEquals("My 1st JUnit 5 test! 😎", testName, () -> "testName is injected correctly"); } https://github.com/junit-team/junit5-samples
- 81. ブラウザを使うやつ Seleniumは市民権を得てきてる感ある けどなかなかうまくできないよね 結構クセ強いし結構不安定だし Geb突っ込んでみたら意外と馴染んだりする どこまで画面でテストするか？ 全部やろうとして死んでるのよく見る
- 82. テスト-課題 テストを自動化してテスト工数を圧縮したい テストを自動化しようとしているが、実装に 時間がかかるので短縮したい テストを自動化しているが実行に時間がかか るので短縮したい
- 83. テスト-返答 テスト工数を圧縮したい 自動化してもすぐは工数減らないよ？ 実装工数に時間がかかる 道具に不慣れなんだから仕方ない 手動で曖昧に済ませてたツケ 実行に時間がかかる （これは普通になんとか）
- 84. テスト自動化 8つの誤解
- 85. 自動化は壊れたプロセスを直す 完全に自動化できなければ成功ではない 自動テストは多くの欠陥を見つける 自動テストは手動テストを置き換える 記録&再生は効果的な手法である ひとつツールで全フェーズをまかなえる 自動化ですぐにスケジュールが前倒しになる 自動化のコストはツールとスクリプトだけだ
- 86. テスト自動化扱いづらい 自動化の文脈でも特に話題にあがりやすい それだけ困っているってことかな よく話題にあがるけど 方向も様々、深さも結構なもの 他の自動化はそこまで詰められていないとも 言えるかも
- 87. テスト自動化は過度な期 待をかけられやすい 8つの誤解の他にも
- 88. 範囲を限定して 制御してみる
- 89. よくあるプロセス テストケース作成 テストスクリプト作成 テスト実行 テスト結果の検証 テストレポートの作成
- 90. 自動化範囲検討(1/2) テストケースの自動化 厳しいってかサポートが得られるくらい テストコーディングの自動化 こっち方面は闇が広がってるから諦めよう 実行の自動化 だいたいできてる
- 91. 自動化範囲検討(2/2) 検証の自動化 assertionのないテストスクリプト、まれに よくある 作った人「目検すればいいじゃん」 報告の自動化 エビデンスの自動取得はできなくはない その先はなんとかしよう
- 92. とっかかりの範囲 テストケースの自動化 -> 範囲外 テストコーディングの自動化 -> 範囲外 実行の自動化 -> ほぼいける 検証の自動化 -> だいたいやる 報告の自動化 -> 補助程度 状況次第ですが
- 93. 期待マネジメントむずい うまくいったりいかなかったり 試行錯誤中です
- 94. テスト自動化-現実 自動化以前の問題がテストの自動化に取り組 むとあぶり出されるのはよくある なぜか「自動化で苦労している」とか言い 出す ふしぎ！ そして「自動化はコストに見合わない」と か言い出す ふしぎ！！ break;
- 95. <<自動化ハイ>> 自動化してみた なんか楽しくて仕方ない あれもこれも自動化したい！！ できたあああああ！！！ 次だああああああ！！！！←これ ここまではいいが、これで作られたものは建 て増し旅館になりがち
- 96. 自動化事情のまとめ
- 97. 高速道路はある
- 98. たまに途中で終わる
- 99. 降りてからは迷路
- 100. こんな現実 ありますよね？
- 101. どう戦っていますか？
- 102. 理想に近づけてますか？
- 103. 楽になっていますか？
- 104. 何のための自動化？
- 105. とか煽るだけ煽って、別の話をします。
- 106. <<験担ぎ>> 実行だけされている自動テスト 何のための自動テストかわかっていない エラーが発生したときに「このエラーは大丈 夫」など言い出したら黄色信号 ゲートウェイとして機能しなくなる テストを通すのが目的になり、不具合があっ てもテストを修正してしまうように……
- 107. “自動化担当”観察記録
- 108. この話は妄想です
- 109. 序章:自動化の夢と現実
- 110. 自動化に夢を見た マネージャー
- 111. チームに求められた 自動化
- 112. 経験者不在
- 113. 手探りの自動化
- 114. 期待通りの動作！
- 115. 期待はずれの成果……
- 116. 徐々に失速
- 117. 序章まとめ GettingStartedレベルはそのまま動く。 でも、どのように使ってどう効果を出し、 どう評価するかの手順書は無い。 現場によるしね。 期待マネジメントの失敗。 過度な期待を負わされ、適切なリソースが 得られず、不得意分野で成果をあげられず、 期待はずれと評されるわけだ。
- 118. 一章:着任、自動化担当
- 119. 自動化担当を召喚
- 120. 現状分析
- 121. 役割の被るもの
- 122. やたら時間のかかるもの
- 123. 半自動（半手動）なもの
- 124. 不安定なもの
- 125. 何しているか誰も わからないもの
- 126. 運用がおかしいもの
- 127. 整理した
- 128. 一章まとめ 浅い知識での自動化は、簡単なことならとも かく、すぐに複雑化する Javaコードでいうと「同じコトをする大量の ユーティリティクラスがコピペで作られる」 状態に近い まずそのリファクタリング（と言うかリスト ラクチャリング）を行った
- 129. 二章:自動化の力
- 130. 秩序を保つCIサーバー
- 131. 様々なツールを導入
- 132. エラーを知らせる パトランプ
- 133. 叫ぶCIサーバー
- 134. 即時対応するチーム
- 135. デプロイメント パイプラインの構築
- 136. 本番リリース ワンクリックデプロイ
- 137. 順風満帆
- 138. 二章まとめ 無作為な自動化適用ではなく、強みをより生 かす方向へ成長させる。 自動化されたユニットテストは存在したが、 即時実行と即時通知によりフィードバック ループは加速。 システムテストの自動化が同じ基盤に追加 され、エビデンスも取得される。 ワンクリックデプロイも可能となり、教科書 的な自動化はこの時点で達成された。
- 139. 三章:崩壊の足音
- 140. 自動化を推進してきた マネージャーの交代
- 141. 援護射撃を失う 自動化担当
- 142. 自動化を維持する フォースの消失
- 143. 自動化のリソース激減
- 144. メンテされなくなる 自動化システム
- 145. 通らなくなる自動テスト
- 146. -Dmaven.test.skip=true
- 147. 黙らされたCIサーバー
- 148. 三章まとめ 自動化を維持するにはコストが必要 だけどそれが確保できなくなった テスト自動化のよくある誤解に「一度自動化 したらあとはずっと動く」があるが、まさに それ 当然のように開発業務が優先され、自動化の維 持をするよりも1機能でも多く作ることが求め られた 結果として、放棄されてしまった
- 149. 終章:残ったもの
- 150. 自動化担当の解任
- 151. 朽ちていく 自動化システム
- 152. 直近の成功ビルド “10日前”
- 153. 最新ソース コンパイル不能
- 154. トリガーの残る ワンクリックデプロイ
- 155. 完
- 156. 色々聞いてみた
- 157. チームにヒアリング マネージャーとユーザーが徒党を組んでやめ させにきた プレッシャーに抗えない文化がある 指示に反対して失敗しても責任が取れない 責任を取る手段も持たない だから行動できない
- 158. マネージャーにヒアリング 自動化は価値をアピールしづらい 聞いても人によってまちまちな説明だし、 チームは説明下手であり、理解しがたい言 葉で話してくる。 純粋な質問である「それって価値あるの？」 が、チームには止めろという指示に捉えられ ているようだ
- 159. ユーザーにヒアリング いいものをより早く作ってほしいだけ なので、無駄なことをやって生産性が下が るならやめてほしい 期待している成果が挙がらないからやり方に も口出しせざるをえない
- 160. この話は妄想です
- 161. 考えてみてください
- 162. どうしようもない？ マネージャーの交代がなければそのまま順調 にいったのでしょうか？ 状況が変わるのは仕方ない けど、その程度で崩壊していいの？ なんかワンクリックデプロイは残ったけど、 何で残った？
- 163. 順調だった？ 混乱してた自動化システムの統制が取れた エビデンスの自動取得もできたし ワンクリックデプロイもできた ……これって順調なの？ なんか落とし穴ない？
- 164. 経験者は必須？ 未経験のチームが作った自動化システムはイ マイチだったようだけど、経験者が居ないと だめなの？ 必要な情報が足りない？ 経験者は他の現場の“スペシャル”を意気 揚々と持ち込んできたりするよ？
- 165. なげっぱで次に行きます
- 166. 私が本当に 言いたかったこと
- 167. 自動化は好きですか？
- 168. 楽になっていますか？ 早く帰れてる？
- 169. 苦労してますよね？ 楽しいかはさておき
- 170. 苦労してるの 私だけじゃないですよね？ （必死）
- 171. 求)苦労話 現実をなんとかしようと なにかしている 機会があればこうしようと思っている やってみたらこんなことになった そういう話をして 次を考える材料にしたい
- 172. 時間切れのため終了 続きは現場で 考えていきましょ