Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Java勢もVSO使いたい!~JavaEE7 on Ubuntu~

2,474 views

Published on

「第26回 #TFSUG Visual Studio Onlineをクロスプラットフォーム開発で使おう」のデモの説明用資料です。プレゼンテーションというよりかは操作手順書ですね。

Published in: Technology
  • Login to see the comments

Java勢もVSO使いたい!~JavaEE7 on Ubuntu~

  1. 1. Java勢もVSO使いたい! ~JavaEE7 on Ubuntu ~ @CubedKachi 第26回 #TFSUG Visual Studio Onlineを クロスプラットフォーム開発で使おう
  2. 2. 上流から下流までコミットしますが、どちらかというとエクセル方眼紙が友達のSEです。 小さなPJの担当なので、PJ管理、設計、開発、テスト、導入、保守まで一通りやります。 ですが、一番の仕事は他のメンバが実力を充分に発揮できるようにすることです。 ←にも書いていますが、 こんな私を泳がせて受け入れてくれている㈱構造計画研究所には感謝しています。 自己紹介的な何か
  3. 3. 今日のトピックス
  4. 4. 今のお仕事がJavaなのでVSOに触る機会が少ないのですが、 クロスプラットフォーム対応という話題なので 「 Linux, NetBeans, Java」という MSさんと縁遠そうなネタで固めてみました。
  5. 5. と、思っていたらJava界隈の大物が MSさんに入ったようなので この手の話題も増えてくると思います。
  6. 6. 今回はVSOの新ビルド機能を使って NetBeansで開発したJavaEE7のWebアプリを AzureにホストしたUbuntuのPayaraに 継続的デプロイする準備を整えます。
  7. 7. まずはサーバの準備から。 話はそれから。
  8. 8. Azureポータル左下の 「新規」を選択します。
  9. 9. 「コンピューティング →仮想マシン →新規」を選択します。
  10. 10. 「UBUNTU →Ubuntu Server 14.04LTS」 を選択します。 「→」を選択します。 お仕事は常にWindowsなので、 ubuntuはほぼ初体験です。
  11. 11. 「仮想マシン名」と「ユーザ名」を指定します。 azureのSSH鍵精製は難しかったので 今回はパスワードで接続します。 Web系に聞かれたら説教されますね。 「→」を選択します。
  12. 12. クラウドサービス名はデフォルトのまま 仮想マシン名と同じにします。 コンソール操作とAPサーバのために、 SSHとHTTP、HTTPSのエンドポイントを 用意しておきます。 「→」を選択します。
  13. 13. デフォルトから特に変更することはありません。 chefもいつかはチャレンジしてみたいですが、 それは別の機会にしましょう。
  14. 14. 仮想マシンのプロビジョニングは 5分ほど待てば完了します。 便利な時代になったものですね。
  15. 15. ダッシュボードから ホストを確認しておきます。
  16. 16. GlassFishではなく Payaraを使ってみよう
  17. 17. サーバへの接続には 「Tera Term」を使用しました。 確認しておいたホスト名を指定し ポート22でSSH接続します。 初めて接続するサーバなので 警告が出ますが続行します。
  18. 18. プレインテキストでユーザ、 パスワードを指定し接続します。 コンソールが表示されれば 接続成功です。
  19. 19. (個人情報を消すのが面倒なので) root権限に昇格します。
  20. 20. Linuxの事はよく分からないで Webで見たHowToに従って操作します。 「aptitude update」というのは、 Windows Updateの「更新プログラムの確認」 みたいなものだと思います(適当)。
  21. 21. なんかたくさんリストが出てきたので 「利用可能な更新プログラム」の一覧 みたいなものなのでしょう(適当)。
  22. 22. お勧めのものだけインストールするということでしょうか? 「シェフの気まぐれ」みたいなものですかね。
  23. 23. 「お勧め」は特になかったようです。
  24. 24. 「add-apt-repository ppa:webupd8team/java」 これはなんとなく想像がつきますね。
  25. 25. 「Java9もあるから気を付けてね」という 確認が出てくるのでEnterで続けます。
  26. 26. 「リポジトリ追加したので jdk8とunzipをインストールしてね」 という感じでしょう(適当)。
  27. 27. 途中でOracleさんの ライセンス確認が入ってきます。 とりあえず「Yes」を選択します。
  28. 28. インストール後はバージョン確認をします。 これはWindowsと同じコマンドです。
  29. 29. JDK8が入ったのでAPサーバを準備します。 「http://bit.ly/1czs5bH」は Payara 4.1.152 Patch 1 (Full Java EE) の ダウンロード用の短縮URLです。
  30. 30. ちょっと待てばダウンロード完了します。 短縮URLを使ったので変な名前で 保存されていることに注意です。
  31. 31. 「/opt」直下に解凍します。
  32. 32. 解凍したPayaraの 実行フォルダに移動します。
  33. 33. GlassFishの場合、初期ドメインが 一つしかないためドメイン指定は不要でしたが、 Payaraではもう一つドメインがあるので 「domain1」を指定して起動します。
  34. 34. PayaraがGlassFishを使っていることが分かりますね。 管理コンソール用のポートが「4848」なので azrueで仮想マシンを立てるときに エンドポイントを設定していないとここで詰みます。
  35. 35. リモートデプロイを行うために、 管理ユーザのパスワードを変更します。
  36. 36. 「admin」の初期パスワードは「」なので、 適当なパスワードを設定します。
  37. 37. リモートデプロイを行うために HTTPS接続で管理コンソールに アクセス出来るように設定します。
  38. 38. ドメインを再起動します。
  39. 39. ブラウザから4848ポートで 管理コンソールに接続できれば 設定完了です。
  40. 40. チームPJの作成から Maven PJの作成まで
  41. 41. チームPJを作成します。 全てはそこから始まります。
  42. 42. 今回はNetBeansを使って進めるので Version controlはGitを選択する必要があります。
  43. 43. 今回はチケット管理の話は割愛して、 リポジトリのクローンから行います。
  44. 44. クローン元のURLをコピーしておきます。
  45. 45. NetBeans 8.0.2を使用します。 インストール時にJavaEEも 含めておく必要があります。
  46. 46. 「チーム→Git→クローン」と選択します。
  47. 47. 先ほどコピーしたURLを入力します。 MSアカウントを入力します
  48. 48. チームPJを作ったばかりなので リポジトリは空っぽです。
  49. 49. 任意の場所にクローンしてください。
  50. 50. まずプロジェクトを作成します。 「Maven→Webアプリケーション」 を選択してください。
  51. 51. Mavenを公開する予定がないなら 任意の名前を付けて大丈夫です。
  52. 52. AppサーバにはGlassFish、 JavaEEのバージョンは7を選択します。 選択したサーバーがIDEで 実行時に呼び出されます。
  53. 53. すぐに触りたくなるのを抑えて まずはコミットしてしまいます。
  54. 54. 速攻でリモートにプッシュします。 リモートの「master」に プッシュしてローカルに 「origin/master」を作るかを 聞かれるので 「はい→はい」と選択します。
  55. 55. VSOのリポジトリにMaven PJが 反映されていることを確認します。
  56. 56. VSOでのMaven PJの ビルドとCI
  57. 57. 「Empty」を選択します。 新しくビルド定義を作成するには 「+」ボタンを押下します。
  58. 58. 「+」ボタンで ビルド手順を追加します。 Mavenを「Add」して 「Close」します。
  59. 59. 「…」を押下して POMファイルを選択します。
  60. 60. 先ほど速攻でpushしたのは POMファイルを選択するためです。
  61. 61. JDKのバージョンと アーキテクチャは Advancedメニューで設定できます。
  62. 62. 「Triggers」タブから 「CI」にチェックを付けると VSOリポジトリにpushされた タイミングで自動的にビルドを行います 「Filters」でどのブランチを トリガーに「含めるか or 除くか」 を設定できます。
  63. 63. 名前とコメントを 入力して保存します。 ビルド定義に反映されます。
  64. 64. CI設定したので PJの設定を変更します。 JDKは1.8を選択します。
  65. 65. フレームワークには JSF(JavaServer Faces) を選択します。
  66. 66. JSFサーブレットURLパターンは 「/faces/*」から「*.xhtml」に 変更しておきます。
  67. 67. コンポーネントは選択せずに 「OK」で設定を確定させます。
  68. 68. pox.xmlが自動更新されたり…
  69. 69. Web.xmlが自動生成されたり…
  70. 70. index.xhtmlが自動生成されたり…
  71. 71. 実行するとNetBeansが GlassFishに自動でデプロイして ブラウザ実行までしてくれます。
  72. 72. 「index.html」は不要なため 忘れないうちに削除しておきます。
  73. 73. ここまでの変更をコミットします。
  74. 74. 速攻でリモートにプッシュします。 CIでビルドのキューが 追加されます
  75. 75. ビルドは無事に 成功したようです。
  76. 76. VSOだけじゃないけれど 継続的デプロイも
  77. 77. 「pom.xml」の<build>に プラグインを追加します。
  78. 78. 今回、追加するのは 「cargo-maven2-plugin」 です。 GlassFish4.x系の リモートデプロイを 行うことが出来ます。 「ホストのURL」、「管理ユー ザ名」、「パスワード」、「管 理用のポート」、「デプロイ先 のドメイン」を指定します。
  79. 79. 続けてデプロイ対象の情報と Webアプリケーションの URLとなるコンテキスト を指定します。 plugin用の依存性を追加します。 どんどん複雑になりますね。
  80. 80. ここまでの変更をコミットします。
  81. 81. pushするとキューが追加されます。
  82. 82. 後はビルドの成功を見届け…、 あれ?
  83. 83. 「あ、これ練習用のサーバ名だ」 そう、CIは失敗するものです。 正常系だけをデモしてもダメなのです。 ワザトデスヨ、ホントウデスヨ。 という訳で気を取り直して、 失敗時に通知を飛ばすように VSOの設定を追加します。
  84. 84. 設定画面の 「Alerts」タブを 選択します。
  85. 85. 「My Alerts」メニューから 「Build Alerts」を選択します。
  86. 86. 「New」を選択します。
  87. 87. ビルド失敗通知の テンプレートを選択します。 細かい設定もクエリを作成できますが 今回はデフォルトで作成します。 これでビルド失敗時にメールが来るはずです。
  88. 88. 間違っていたホスト名を 正しく修正して
  89. 89. コミットして
  90. 90. pushしたら、 ビルドのキューが追加されて
  91. 91. 今度こそ、ビルドの成功を見届け…、 あれ?
  92. 92. 「あ、そう言えば 手動でデプロイ試したの消し忘れてた」 そう、CIは失敗するものです。 正常系だけをデモしてもダメなのです。 ワザトデスヨ、ホントウデスヨ。 し、失敗通知のメールが来るか テストしただけだから(震え声)
  93. 93. ほら、ちゃんとVSOから お知らせが来てます。 これをデモしたかったのです。 間違えた訳じゃないですよ。
  94. 94. こんなの、一行設定足すだけです。 ちょっと、忘れてただけですよ。
  95. 95. コミットして
  96. 96. pushしたら、 ビルドのキューが追加されて
  97. 97. 今度こそ、…………ユニバァァァス!! コホン、ビルドの成功を見届けて
  98. 98. デプロイ先のURLを確認します。 問題ありませんね。
  99. 99. ソースをそれっぽく変更して CIしてからURLにアクセスして 見せたら綺麗に締まるはず…
  100. 100. まずローカルでリビルドして… _人人人人人人_ > 突然の死 <  ̄Y^Y^Y^Y^Y ̄
  101. 101. 「あ、これアカン奴や」
  102. 102. http://knowledge.sorich.jp/?Java%2FMaven%2FMavenの特徴 Mavenのビルドライフサイクルでの「package」フェーズでデプロイ用の プラグインを実行する設定にしているとNetBeans上でビルドしたときは常に (「install」フェーズが適用されるので)デプロイが行われてしまいます。 これは致命的なスロービルドに繋がります。そして、私が諸先輩方に怒られます。
  103. 103. 困った時は同じ失敗をしている人を探します。 親切な人たちが解決方法を教えてくれます。 いい時代になりましたね。 どうやらゴールに 「cargo:redeploy」を 指定すれば良いようです。 http://stackoverflow.com/questions/17045318/redeploy- remote-glassfish-with-cargo-fails http://ufasoli.blogspot.fr/2013/07/redeploying- to-remote-glassfish-with.html
  104. 104. 「force=true」も削除しておきます。 「executions」を削除します。
  105. 105. JSFのソースは除いた状態で コミットして
  106. 106. pushしたら、 ビルドのキューが追加されて
  107. 107. ビルドの成功を見届けます。 ただし、今度はデプロイは実行されません。
  108. 108. VSOのビルドの設定を変更します。 現在のGoal(s)は 「package」だけですが…、
  109. 109. 「clean package cargo:redeploy」に変更します。 これで、warファイルの作成後に プラグインによるリデプロイが実行されます。
  110. 110. 保存して 手動でビルドに キューを追加します。
  111. 111. ビルドの成功を見届けます。 今度はデプロイまで実行されています。
  112. 112. 先ほどコミットし損なった 「index.xhtml」を
  113. 113. コミットして
  114. 114. pushしたら、 ビルドのキューが追加されて
  115. 115. ビルドの成功を見届けます。 今度もデプロイまで実行されています。
  116. 116. デプロイ先のURLを確認します。 キチンとコンテンツが更新されています。 これで安心して終了できますね。

×