<< September 2017 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 >>

スポンサーサイト

0

    一定期間更新がないため広告を表示しています

    スポンサードリンク * - * * - * - * - -

    第1回大阪Jenkins勉強会に参加してCIの導入について学ぶ

    0
       第1回大阪Jenkins勉強会の参加の動機

      最近はコーディング以外の作業を自動化することが注目されているようで、私もCI(継続的なインテグレーション)に興味を持ち始めた。
      今の現場ではTracLightningを使っていてHudosonも入っているが使った事は無い。「コミットの度に自動的にビルドができて便利ですよ」という人もいたが、当時は案件も忙しくその機能がもたらす価値も理解できずにいた。
      だが、CIを導入すると何が変わるのかを学ぶため、勉強会に参加した。


      発表内容

      @kiy0takaさん Jenkins入門 30分
      @yugolfさん 甲賀流Jenkins活用術 30分
      @shinsukeodaさん .NET なプロジェクトでも Jenkins を使ってみた 15分

      LT
      @irofさん
      @yohhatuさん
      @kohsukekawaさん


      @kiy0takaさん Jenkins入門 30分

      Jenkinsの初心者向けの紹介とその導入のデモが行われた、
      そのデモにより、Jenkinsの導入がいかに簡単で、30分もあれば導入できることが良くわかった。
      いくつか導入方法があるが、Javaコマンドで java -jar jenkins.warのコマンド一発でも導入できるし、warファイルをWebサーバーにでデプロイするだけでもいいし、また、各OSプラットフォームごとにインストーラが用意されている。
      必要なJDKなどのライブラリも、Jenkinsの管理画面からGUIで簡単に設定することが可能となっている。
      今の現場ではTracLingtningなのでこの問題はクリアしているが。

      また、導入後の実際の使い方についても簡単なデモがあった。
      Jenkinsにジョブを登録しておけば、そのジョブによってAntやMavenなどのビルドツールを自動起動ができるようになる。
      Cronのように定期的に起動することもできるし、一定時間おきに連携するSCM(Subversionなど)を監視してコミットがあればジョブを起動するなど、また、手動で起動することもできる。

      ジョブを起動すると登録されたジョブが実行され、たとえばビルドなどが自動的に実行され、ビルドでエラーが発生した場合はメールなどで自動通知される。ジョブにはJUnitの自動テストやデプロイ作業もさせることができるらしい。

      ジョブでは他にもいろいろな事ができるが、基本的なこの仕組みを利用することで、コーディング以外の様々な作業を自動化することができるらしい。
      継続的なインテグレーションがもたらす効果は冒頭で説明があったが、そのツールの導入がいかに簡単で敷居の低いものかがとてもよくわかった。

      私の今の現場の話だが、JUnitが管理されておらず、仕様変更などでいつの間にかFailが発生していても、そのままにされていることも少なくない。手動による試験にはコストがかけられているのだが、JUnitのメンテナンスまでは保障されていない。
      そういう状況なので、Jenkinsを導入するといきなりエラーメールが発生しまくることが想像できる。
      導入の際には、そこだけは気をつけなくてはいけない。登録するジョブには気を付けて、自動テストについては少しずつメンテナンスが保障されている範囲を整備していくしかなさそうだと思った。


      @yugolfさん 甲賀流Jenkins活用術 30分

      TISで開発されている社内フレームワークのXenlon(神龍)の開発にどのようにJenkinsが利用されているかの実践的な活用事例の紹介。
      3カ月に1回というリリース周期の開発の為には、Jenkinsがなければとても回らないと、その価値が強調されていた。

      Jenkinsのジョブは、日中・夜間・リリース前で役割を分けて導入されている。
      日中のジョブは15分おきSCMをポーリングで監視して実行され、リアルタイム性の高いものが登録されている。たとえば、ビルドやJUnit、CheckStyle、他、JavaのStatic変数が危険な使われていないかのチェックをするプラグインなども登録されているらしい。
      夜間は、特に時間のかかるもので定期的に行うべきものが登録されている。たとえば、各DBプラットフォームでのDBテスト、カバレッジレポートやJavaDocの生成、セキュリティチェックツールの実行など。
      リリース前は、任意のタイミングで手動でおこなうジョブが登録される。リリース作業をシェルで自動化されたものなどがジョブに登録されているらしい。

      最後にCIの効果として、品質の可視化、問題の早期発見、コミット問題の解決の短縮などがあげられていた。



      @shinsukeodaさん .NET なプロジェクトでも Jenkins を使ってみた 15分

      .NETでのJenkins導入について気を付けならなければならない事など導入事例が紹介された。
      私は、.NETを触る機会がなかったので、FxCopやMSBuildは初めて聞いたものだが、.NETならではの苦労が語られた。
      MSDNやVisualStudioは高価だが、無料のツールを使った場合のJenkins導入事例について語られていた。

      最初はGUIはサイコーだとJenkinsのGUIを押していたが、最後の最後でやっぱりCUIがサイコーだと落とされた。
      つまりは、GUIは設定・導入がとても便利だが、自動化には向いていない。
      GUIで導入・設定できて、作業の自動化にむいたCUIの両方に対応していることが大事だということが語られた。


      ライトニングトークス

      @irofさんは、CIを導入したことでコードが腐らないことを上げられていた。
      @yohhatuさんも同じメリットを大阪の551の蓬莱のCMチックにCI導入の効果が語られた。
      「私の環境では動いていた」で取られる時間ほどあほらしいものはないと思った。

      最後のLTでは、@kohsukekawaさんによる、HudosonからJenkinsのアップグレードがいかに簡単なものかデモを交えて紹介された。
      名前以外(あとはロゴ?)の中身は何も変わっていないそうで、デモを参考にすれば簡単にHudosonからJenkinsに切り替える事ができることが示された。動画によるビデオレター的なTLで斬新だった。


      まとめ

      勉強会に参加して、「価値はありそうだが、JUnitのメンテナンスをやらないといけないし、誰かが導入したいといまではいいかな」と思っていたのが、「Jenkinsが導入できるよう現場に掛け合いたい。他の人がやりたいというのは待ってられない」と気持ちが変わった。

      導入が簡単だということも理由の一つだが、@irofさんの言う「コードが腐らないこと」がとても大切なことだと思える。今の現場ではJUnitはメンテナンスされていないので、せっかく作っても時間がたつとともに仕様変更などが入り、メンテナンスされないテストは価値がなくなってしまう。
      また、各メンバーのローカルのDB設定でないと動かないテストがあったりすると、下手動かすとデータベースのデータを壊す事故も起こりえる心配があり、他人が作ったテストを実行するのも気を使うような状況になっている。
      CIを導入することでコミットの度にチェックされるようになれば、それを防ぐことができ、結果、JUnitの価値を高める事ができるはずだ。

      他、今の現場ではビルド作業やデプロイ作業は、何人かで担当して定期的に行っているので、こういった作業も自動化することができるというメリットももちろんある。
      また、デプロイ環境は、リリースのタイミングでどこまでのリビジョンでデプロイされているかが管理されているので、その運用に支障をきたさないように気を使う必要もある。今の受け入れテスト用のデプロイ環境と、CI様のデプロイ環境を2種類、用意する必要はあるのだろうか。

      今の現場に導入するには、少しづつ自動テストをメンテナンスしていく事と、受け入れ環境とのデプロイ環境との調整、他、現行リリースの障害管理用のブランチと次期リリース管理用のトランクで枝分かれしたソースをCIでどう管理していくかなどの課題が残っている。個人的には自動テストの価値を高める事が悲願だが、プロジェクト的にも不要な作業が自動化でき、コミット時の問題が短縮される効果もあるので、なんとか導入にこぎつけたいと心を改めた。


      最後に、本日の貴重な導入事例を共有する勉強会の場を設けてくださった、講師・運営の方々に感謝申し上げます。貴重な機会をありがとうございました。

      よっしー * システム開発案件 * 01:48 * comments(0) * trackbacks(0) * - -

      「レガシーコード改善ガイド」は久しぶりに読んでみたい技術本だ

      0
         近々、去年開発したシステムの2次開発を行う予定があり、新しいメンバーとどのように作業をすすめていこうか考えているところだ。
         去年は時間があまりなく、経験2年目のメンバーにまかした機能のコードレビューなどの面倒を見ることができず、コードに重複があったり、かなりの改善の余地を残している。
         それを新しいメンバーにどう直してもらえばいいのかを考えている。

          レガシーコード改善ガイド (Object Oriented SELECTION) はそれを考えるいいヒントになるかもしれない。これは久しぶりにゆっくり読んでみたいかも。
         Codezinの連載記事の紹介を読んでみたところ、少しヒントになりそうなことがちらほらあった。
         記事のサンプルに、サーブレットを取り上げていることもWebシステム開発にも摘要できるのではないだろうかと淡い期待を抱く。


         予定では、まずはデータベースにアクセスする部分のソースコードに重複があり、SQL文をかいているコードに、同じようなファイル・ロジックがたくさんある部分を整理する必要があり、Unitテストをどのような単位で作っていくと効果が高いか検討中だった。
         業務ロジックとデータベース処理を行う実装は、システム全体で、2つの層に分け整理してあるのだが、まずは、データベースアクセス層に対して、コードの重複などを取り除いて、コードを整理して、小規模なリファクタリングを行い、Unitテストを書いて、コードを保護するところから始めることを考えていた。

         Codezineの連載記事の第2回で紹介されていた方法に「仕様化テスト」というのがあり、これも実際にやってみたいと思った。
         設計仕様書などのドキュメントがはプログラムを動かしながら画面の仕様を確認していくことも多くあるのだが、仕様のより細かい部分を確かめていく場合で、画面の細かいテストに手間がかかる場合は、Unitテストを組んで動かして、仕様を確認していくことも有効だ。

         また、ソースコードを整理していくことの意義について、新しいメンバーにどう意識をもってもらうか、何か工夫が必要だと思っていたが、単体テストの導入はその意識をメンバーに持ってもらうことにつながると前から考えていた。

         連載記事の第4回でも、下記の様な発言がある

         テストを書くためには依存関係を排除する必要があり、実際にテストを書くことで、依存関係を排除する具体的な方法が分かる

         この考え方はよくわかる、Unitテストを活用しようとしていた狙いもここにある。Unitテストを書くためには、処理をテストがしやすい単位に分けて整理する必要があり、複雑で長い読みにくいコードは、Unitテストのつくりようがないものだ。

         Unitテストをプロジェクトを導入しておけば、上記のような意識から、ソースコードが自然ときれいに整理されていくという仮説をずっと考えていた。
         今回の2次開発プロジェクトで、新しいメンバーが入ってくるので、この仮説を検証してみようと思う。

         参考URL: 
        「レガシーコード改善ガイド」のススメ


         
        よっしー * Webシステム開発(Java/Servlet) * 07:42 * comments(9) * trackbacks(0) * - -

        作業管理にTracのチケットを活用

        0
          システム開発の作業管理に、Trac Lightningを活用しています。

           7名ぐらいの開発メンバーの案件で3か月ぐらい導入したところ、作業の段取りや、進捗管理、作業の見える化に役立った。そこで、新しい6名ぐらいの開発メンバーの案件でも、取り入れてみることにした。
           これまでにやってきたのExcelによる管理や、社内向けの報告等の兼ね合いなどを心配されていたリーダさんにも、初めは反対色が濃かったのだが、それらの課題を整理して、Trac導入による利点などを伝えたことで、リーダーの了解を得ることができた。
           そこで、今回、新しい案件において、Tracを導入する狙い(目的)とそれをどのように行うか(手段)をまとめようと思う。


          Tracを導入する狙い(目的)
           目的としては次のようなものがある。

           1.作業の段取り
             チケットという単位で、やるべきタスクや、課題などを一つ一つ整理することで、やらなければならないことを洗い出したり、誰がやるべきか、いつまでにやるべきかといった軸で整理する。
             また、各作業がどれぐらい進んだかを進捗率でつど記録を残したり、Wiki形式のメモ書きで、各タスクごとにやるべきこと、やったことの覚書をのこすこともできる。


           2.進捗の管理
             上記のチケットという作業単位で、期限を設けたり、各作業の担当者に進捗率を記入してもらうことで、誰が何をやっていて、いつまでに終わらせなければいけなくて、それがいまどこまで進んでいるかを管理する事が出来る。
             上記に加えて、タスク管理用のデータベースを拡張して、予定工数と実績工数を記録できる欄を用意して、予実の管理もおこなうことにした。
             
           3.作業の見える化
             上記のようにチケットという単位で、作業を整理することで誰が今、どのような作業を、いつまでの締め切りで、どこまで進んでいるのかを把握しやすくしている。
             残っているチケットの数を一覧表示して確認したり、ガントチャート形式で表示するなどして、現状がみえるようにすることができる。

           4. コミュニケーションの活性化
             TracのもつWiki機能を利用することで、装飾などを含めたレイアウトや見せ方に工夫のあるWebページを手軽に作ることができ、それを仕様書の作成に活用することで、各メンバーが担当している画面・機能の仕様のメモ書きや覚書などを、各人で残してみんなでみることができる。
             システムの設計書が整備されていなくて、仕様に不明点があったり、隠れ仕様が多くあったりすることで、仕様の把握に時間がかかり、作業の遅れにつながることはよくあることで、メンバーの意見を聞いても、いつも問題になっている。
             それを解決するために、細かい仕様についての覚書やメモ書きを、Wikiを利用したWebページに残してもらい、みんなでみるという手段が有効に働く。
             また、Wikiに残した事柄を下書きとして、本来の詳細設計書等に、清書しなおすといった使い方も考えている。



          Tracをどのように活用するか(手段)
           1. チケット管理
             作業や課題をチケットという単位で管理する。チケットの作業を担当する人を決めたり、その作業の期限を決めたりすることで、作業の段取りや進捗状況を管理することができる。
             また、Wiki形式でメモ書きを残せるので、やらなければならないことを箇条書きしたり、やり終えたことを消して行ったりすることを、見やすさを考えてデザイン・レイアウトを工夫したWeb画面を、気軽に残すことができる。
             今回の案件では、作業用のデータベースを拡張して、予定と実績の項目を持たせ、予実の管理もできるようにした。
             未着手の作業や進行中の作業を詳細設計完了やコーディング完了などのマイルストーンごとに一覧表示したり、自分の担当分の作業のみを一覧表示したりするときに一緒に、各作業の予定工数と現在までの実績工数を一覧形式で確認できるように、予定と実績の状況を把握しやすいように見える化を行っている。
             予実の管理は、実績工数をきちんとのこしておくことで、後で集計して、最初に建てた見積もりとの差異をまとめたり、その原因を追及・分析することにも役立つ。
             チケット管理を行うことで、各メンバーが作業段取りを立てて進み、プロジェクト途中では現状が見えるようにして、終われば予定と実績を振り返ることができる。


           2.  Wiki機能
             装飾やレイアウト加えて、見やすさを考えたWebページを、HTMLタグを駆使しなくても、簡単なルール・記号による記述によって、気軽にWebページを作成することができる。
             前回や今回の案件では、仕様の不明点が多くて作業が遅れるという問題を対処・改善するために、Wikiを利用して仕様をWebページ形式でまとめ、各仕様の細かい内容を気づいた人から、まずは覚書というレベルで、記録を残すという方法をとった。
             各画面・機能の仕様を、見やすさを考えて残し、それを他の人が見るという方法をとることで、少しづつ、仕様の不明点などをメンバーのみんなで把握していけるように考えた。
           
           3. フォーラム機能
             案件に関する話題や、質問、情報を共有すべき事柄を、メンバーのみんなが見る掲示板に書き残すことができる。
             質問やトピックなど分類やテーマを立てて、整理したり、メンバー間で決められたテーマに寄せられた意見や質問に答えることで、話し合ったり助け合ったりすことができ、メンバー間のコミュニケーションの活性化に活用できる。

           4. 構成管理システムとの連携
             ソースコードの構成管理を行うSubversionシステムと連携することで、フォーラムの掲示板から、話題が対象にしているソースコードのコミット履歴にリンクを張ったり、各メンバーで管理している作業のチケットに対応するソースコードのコミット履歴にリンクを張ったりすることができる。
             意識の共有や、作業の管理をソースコードやその変更履歴と対応づけて管理することで、ソースコードレベルで情報の共有や作業の管理をおこなうことにも役立てることができる為、ソースコードレベルでのメンバー間の意識の共有がより進む。



          従来のExcelの管理に比べてよかった点

           1.チケット管理により、メンバーの自主性が育つ
            作業管理はこれまでは義務のようなものだったが、やるべきことや課題をチケットという単位で管理して、やらなければならないことを把握できるようにしたことで、作業を行う人がより主体的になり、場合には自分でチケットを発行したりもする。
            そうしたことで、義務感から作業管理をするのではなく、自主的に作業管理を行うようにプロジェクトのメンバーの意識が変わってきた。
            きちんと日報を書けなどと口を酸っぱくして言っても、なかなか真面目にとりくんでくれることは少ないが、もっと自主的に作業の段取りをメンバー各自が考えてくれるようにかわってくることで、管理する側も負荷がなくなってきて、メンバーと作業管理者の双方でよい関係が築かれつつある。

           2.課題管理が進む
            これまではExcelシートなどに、課題を報告・管理する欄を設けたものを用意して、メンバーに記入してもらったりしていたが、なにぶんExcelシートは一覧性を重視すると記入する欄が小さくなり、メンバーがなかなかきちんと書いてくれない。
            小さい欄が、より小さくなっていき、書かれている内容も短く、キーワードだけが書かれているような状態になり、ほとんど日本語の文章になっていないこともあった。
            結局、書いた本人した、意味を解読できないものがたくさんならぶことになり、他のみんながみても何を書いているのかが解らず、起きている問題をみんなで共有する役には立たなかった。
            課題をチケット管理にしたことで、Webページの広い、自由なスペースを使う事ができ、メンバーの報告する内容も、みんなが読むことを意識して、きちんとした日本語で報告されることが多くなってきた。

           



           



           
          よっしー * ファシリテーション * 01:02 * comments(0) * trackbacks(0) * - -

          Slim3と Google App Engineは久しぶりに研究してみたい技術だ

          0
            きっかけは敷居の低さ

             どうせ、淘汰されて使われなくなるから、勉強しても無駄になるんじゃないかなという恐れから、新しいフレームワークやAjaxへの新しい技術の勉強に、最近消極的になっていた。
             そんな中、Google App Engine for Javaは久しぶりに勉強してみたいと思った。

             5年前ぐらい前には、自分でWebアプリを作って公開しようと思っても、Javaに対応したレンタルサーバーは安くても月5000円ぐらいかかったものだ。
             安く借りれるところは、Xrea.comやロリポップなどで、対応しているのはPHPアプリぐらいだった。

             せめてRubyで安く使えるところは無いだろうかと思って探していたところ、見つけたのがGoogle App Engine for Javaだった。
             こういったものを無料で利用できるなんて、今の人たちはなんて恵まれているんだろう。


            今後市場にどう受け入れられていくのか

             せっかく新技術を勉強しても、使われなくなって時間を無駄にしてしまうというのが、新しい技術を覚える上での課題だった。
             でも、それなら、たとえ淘汰されて使われなくなっても、無駄にならないものを選んで勉強すればいい。
             Google App EngineやSlime3を勉強しても、仕事で使うことがなかったり、結局だれも使わなくなって、淘汰されてしまうかもしれない。
             だけど、クラウド・コンピューティングという考え方やそれを支える技術の概念自体は、今までのリレーショナルデータベースをベースにした業務システムにない、新しいアイデア、新しい利用のされ方として、残っていくかもしれない。

             ホストコンピューター → ビジュアルプログラミングを取り入れたのクライアント/サーバー型システム → Webシステム → リッチクライアント? という流れで、世の中のニーズによって市場に受け入れられきた歴史の中で、新しく生まれる考え方にならないだろうか?


            いままで繰り返されてきたこと、ずっと問題としてあり続けていること

             システムの導入にかかるコストや、運用の課題は、何年たってもなくならない問題として、課題であり続けている。小さい店舗や会社が、売上の管理や、業務の流れを管理しようと思っても、ちょっと支店間でネットワークをつなごうと思うと、回線利用費やインフラ周りで何百万もの費用がかかってしまう。
             ファイルメーカーやAccess、弥生会計など、個人レベルや、ネットワークを介しない1店舗・会社で完結する程度のアプリケーションソフトの導入と比べると、システムの導入には大きな敷居を伴う。

             とここまで書くと、結局はWebシステムが出始めたころに、市場に期待されていたこととあまり変わり映えがしない様な気がするなあ。
             うーん、どうなるのかわからないけれど、現われては消えていく、他の星の数ほどあった技術・概念とは一緒にせず、ユーザーに所有されない、分散化されたインフラで運用されるシステムが、今後、市場にどのように受け入れられていくのか、冷静な目で観察を続けていった方がいいかもしれない。

            ユーザーに所有されない、分散化されたインフラで運用されるシステムに今感じる魅力

             Google App Engine for Javaにひかれるポイント
            ・5年前なら月安くても月5000円必要だったものが今はタダ!
            ・Javaサーブレットが使えて、それをgoogleの多重化された分散コンピューターにおいて利用できる
            ・永続化に使えるBigTableは、Key−Value型データベースというもので、従来のRDBの考え方はそのまま使えないのがデメリットだが、逆に運用面や可用性を考えると新しい可能性が開けてくる予感がする

             Slim3に惹かれるポイント
            ・設定より規約を重視する考え方など、Rubyで今話題性のある考え方が取り入れられていること
            ・Springや、Seaser2などのように堅牢なビジネスロジックの管理を求めらる業務アプリケーションとは異なり、個人で展開するような小規模のシンプルなアプリケーションに向いている(と思う)
            ・現在、開発中で毎日のようにソースコードが更新されているのが、公開SVN上で拝見できる。リファクタリングされたソースコードの差分を見ていると本当に勉強になるものが多い


             これは、今のチームのメンバーにも、ぜひ勉強することをお勧めしたいなあ。
            仕事でやるプログラミングでは、やっぱり品質や堅牢性、保守性を高めるためのシステムテストが大切だし、、開発者本人の手を離れても問題なく運用が進むためにも、設計書等のドキュメントの整備も怠れない、また、設計書の基づいた、平易で複雑ではないソースコードを書かなくてはいけないので、どうしても仕事でやる開発は保守的で、確実に結果を残せるものになってしまう。
             個人でやる分については、そういった垣根・制約・制限を取っ払って、新しい事にどんどんチャレンジしてみたい。


            よっしー * クラウド技術(Google App Engine) * 02:29 * comments(0) * trackbacks(0) * - -
            このページの先頭へ