Embed Size (px)
Citation preview
Java勢もVSO使いたい!～JavaEE7 on Ubuntu ～
@CubedKachi
第26回 #TFSUGVisual Studio Onlineをクロスプラットフォーム開発で使おう
上流から下流までコミットしますが、どちらかというとエクセル方眼紙が友達のSEです。小さなPJの担当なので、PJ管理、設計、開発、テスト、導入、保守まで一通りやります。ですが、一番の仕事は他のメンバが実力を充分に発揮できるようにすることです。←にも書いていますが、こんな私を泳がせて受け入れてくれている㈱構造計画研究所には感謝しています。
自己紹介的な何か
今日のトピックス
今のお仕事がJavaなのでVSOに触る機会が少ないのですが、クロスプラットフォーム対応という話題なので
「 Linux, NetBeans, Java」というMSさんと縁遠そうなネタで固めてみました。
と、思っていたらJava界隈の大物がMSさんに入ったようなので
この手の話題も増えてくると思います。
今回はVSOの新ビルド機能を使ってNetBeansで開発したJavaEE7のWebアプリを
AzureにホストしたUbuntuのPayaraに継続的デプロイする準備を整えます。
まずはサーバの準備から。話はそれから。
Azureポータル左下の「新規」を選択します。
「コンピューティング→仮想マシン
→新規」を選択します。
「UBUNTU→Ubuntu Server 14.04LTS」
を選択します。
「→」を選択します。
お仕事は常にWindowsなので、ubuntuはほぼ初体験です。
「仮想マシン名」と「ユーザ名」を指定します。azureのSSH鍵精製は難しかったので今回はパスワードで接続します。
Web系に聞かれたら説教されますね。
「→」を選択します。
クラウドサービス名はデフォルトのまま仮想マシン名と同じにします。
コンソール操作とAPサーバのために、SSHとHTTP、HTTPSのエンドポイントを
用意しておきます。
「→」を選択します。
デフォルトから特に変更することはありません。chefもいつかはチャレンジしてみたいですが、
それは別の機会にしましょう。
仮想マシンのプロビジョニングは５分ほど待てば完了します。
便利な時代になったものですね。
ダッシュボードからホストを確認しておきます。
GlassFishではなくPayaraを使ってみよう
サーバへの接続には「Tera Term」を使用しました。
確認しておいたホスト名を指定しポート22でSSH接続します。
初めて接続するサーバなので警告が出ますが続行します。
プレインテキストでユーザ、パスワードを指定し接続します。
コンソールが表示されれば接続成功です。
(個人情報を消すのが面倒なので)root権限に昇格します。
Linuxの事はよく分からないでWebで見たHowToに従って操作します。「aptitude update」というのは、Windows Updateの「更新プログラムの確認」みたいなものだと思います(適当)。
なんかたくさんリストが出てきたので「利用可能な更新プログラム」の一覧みたいなものなのでしょう(適当)。
お勧めのものだけインストールするということでしょうか？「シェフの気まぐれ」みたいなものですかね。
「お勧め」は特になかったようです。
「add-apt-repository ppa:webupd8team/java」これはなんとなく想像がつきますね。
「Java9もあるから気を付けてね」という確認が出てくるのでEnterで続けます。
「リポジトリ追加したのでjdk8とunzipをインストールしてね」
という感じでしょう(適当)。
途中でOracleさんのライセンス確認が入ってきます。
とりあえず「Yes」を選択します。
インストール後はバージョン確認をします。これはWindowsと同じコマンドです。
JDK8が入ったのでAPサーバを準備します。「http://bit.ly/1czs5bH」は
Payara 4.1.152 Patch 1 (Full Java EE) のダウンロード用の短縮URLです。
ちょっと待てばダウンロード完了します。短縮URLを使ったので変な名前で保存されていることに注意です。
「/opt」直下に解凍します。
解凍したPayaraの実行フォルダに移動します。
GlassFishの場合、初期ドメインが一つしかないためドメイン指定は不要でしたが、
Payaraではもう一つドメインがあるので「domain1」を指定して起動します。
PayaraがGlassFishを使っていることが分かりますね。管理コンソール用のポートが「4848」なので
azrueで仮想マシンを立てるときにエンドポイントを設定していないとここで詰みます。
リモートデプロイを行うために、管理ユーザのパスワードを変更します。
「admin」の初期パスワードは「」なので、適当なパスワードを設定します。
リモートデプロイを行うためにHTTPS接続で管理コンソールに
アクセス出来るように設定します。
ドメインを再起動します。
ブラウザから4848ポートで管理コンソールに接続できれば
設定完了です。
チームPJの作成からMaven PJの作成まで
チームPJを作成します。全てはそこから始まります。
今回はNetBeansを使って進めるのでVersion controlはGitを選択する必要があります。
今回はチケット管理の話は割愛して、リポジトリのクローンから行います。
クローン元のURLをコピーしておきます。
NetBeans 8.0.2を使用します。インストール時にJavaEEも含めておく必要があります。
「チーム→Git→クローン」と選択します。
先ほどコピーしたURLを入力します。
MSアカウントを入力します
チームPJを作ったばかりなのでリポジトリは空っぽです。
任意の場所にクローンしてください。
まずプロジェクトを作成します。
「Maven→Webアプリケーション」を選択してください。
Mavenを公開する予定がないなら任意の名前を付けて大丈夫です。
AppサーバにはGlassFish、JavaEEのバージョンは7を選択します。
選択したサーバーがIDEで実行時に呼び出されます。
すぐに触りたくなるのを抑えてまずはコミットしてしまいます。
速攻でリモートにプッシュします。
リモートの「master」にプッシュしてローカルに
「origin/master」を作るかを聞かれるので
「はい→はい」と選択します。
VSOのリポジトリにMaven PJが反映されていることを確認します。
VSOでのMaven PJのビルドとCI
「Empty」を選択します。
新しくビルド定義を作成するには「＋」ボタンを押下します。
「＋」ボタンでビルド手順を追加します。
Mavenを「Add」して「Close」します。
「…」を押下してPOMファイルを選択します。
先ほど速攻でpushしたのはPOMファイルを選択するためです。
JDKのバージョンとアーキテクチャは
Advancedメニューで設定できます。
「Triggers」タブから「CI」にチェックを付けるとVSOリポジトリにpushされた
タイミングで自動的にビルドを行います
「Filters」でどのブランチをトリガーに「含めるか or 除くか」
を設定できます。
名前とコメントを入力して保存します。
ビルド定義に反映されます。
CI設定したのでPJの設定を変更します。
JDKは1.8を選択します。
フレームワークにはJSF(JavaServer Faces)
を選択します。
JSFサーブレットURLパターンは「/faces/*」から「*.xhtml」に
変更しておきます。
コンポーネントは選択せずに「OK」で設定を確定させます。
pox.xmlが自動更新されたり…
Web.xmlが自動生成されたり…
index.xhtmlが自動生成されたり…
実行するとNetBeansがGlassFishに自動でデプロイしてブラウザ実行までしてくれます。
「index.html」は不要なため忘れないうちに削除しておきます。
ここまでの変更をコミットします。
速攻でリモートにプッシュします。
CIでビルドのキューが追加されます
ビルドは無事に成功したようです。
VSOだけじゃないけれど継続的デプロイも
「pom.xml」の<build>にプラグインを追加します。
今回、追加するのは「cargo-maven2-plugin」
です。
GlassFish4.x系のリモートデプロイを行うことが出来ます。
「ホストのURL」、「管理ユーザ名」、「パスワード」、「管理用のポート」、「デプロイ先のドメイン」を指定します。
続けてデプロイ対象の情報とWebアプリケーションのURLとなるコンテキスト
を指定します。
plugin用の依存性を追加します。どんどん複雑になりますね。
ここまでの変更をコミットします。
pushするとキューが追加されます。
後はビルドの成功を見届け…、あれ？
「あ、これ練習用のサーバ名だ」
そう、CIは失敗するものです。正常系だけをデモしてもダメなのです。ワザトデスヨ、ホントウデスヨ。 という訳で気を取り直して、
失敗時に通知を飛ばすようにVSOの設定を追加します。
設定画面の「Alerts」タブを選択します。
「My Alerts」メニューから「Build Alerts」を選択します。
「New」を選択します。
ビルド失敗通知のテンプレートを選択します。
細かい設定もクエリを作成できますが今回はデフォルトで作成します。
これでビルド失敗時にメールが来るはずです。
間違っていたホスト名を正しく修正して
コミットして
pushしたら、ビルドのキューが追加されて
今度こそ、ビルドの成功を見届け…、あれ？
「あ、そう言えば手動でデプロイ試したの消し忘れてた」
そう、CIは失敗するものです。正常系だけをデモしてもダメなのです。ワザトデスヨ、ホントウデスヨ。
し、失敗通知のメールが来るかテストしただけだから(震え声)
ほら、ちゃんとVSOからお知らせが来てます。
これをデモしたかったのです。間違えた訳じゃないですよ。
こんなの、一行設定足すだけです。ちょっと、忘れてただけですよ。
コミットして
pushしたら、ビルドのキューが追加されて
今度こそ、…………ユニバァァァス!!コホン、ビルドの成功を見届けて
デプロイ先のURLを確認します。問題ありませんね。
ソースをそれっぽく変更してCIしてからURLにアクセスして見せたら綺麗に締まるはず…
まずローカルでリビルドして…
＿人人人人人人＿＞ 突然の死 ＜￣Y^Y^Y^Y^Y￣
「あ、これアカン奴や」
http://knowledge.sorich.jp/?Java%2FMaven%2FMavenの特徴
Mavenのビルドライフサイクルでの「package」フェーズでデプロイ用のプラグインを実行する設定にしているとNetBeans上でビルドしたときは常に
(「install」フェーズが適用されるので)デプロイが行われてしまいます。これは致命的なスロービルドに繋がります。そして、私が諸先輩方に怒られます。
困った時は同じ失敗をしている人を探します。親切な人たちが解決方法を教えてくれます。
いい時代になりましたね。
どうやらゴールに「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
「force=true」も削除しておきます。
「executions」を削除します。
JSFのソースは除いた状態でコミットして
pushしたら、ビルドのキューが追加されて
ビルドの成功を見届けます。ただし、今度はデプロイは実行されません。
VSOのビルドの設定を変更します。現在のGoal(s)は
「package」だけですが…、
「clean package cargo:redeploy」に変更します。これで、warファイルの作成後に
プラグインによるリデプロイが実行されます。
保存して 手動でビルドにキューを追加します。
ビルドの成功を見届けます。今度はデプロイまで実行されています。
先ほどコミットし損なった「index.xhtml」を
コミットして
pushしたら、ビルドのキューが追加されて
ビルドの成功を見届けます。今度もデプロイまで実行されています。
デプロイ先のURLを確認します。キチンとコンテンツが更新されています。
これで安心して終了できますね。
