狠狠撸

狠狠撸Share a Scribd company logo
Java勢もVSO使いたい!
~JavaEE7 on Ubuntu ~
@CubedKachi
第26回 #TFSUG
Visual 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もいつかはチャレンジしてみたいですが、
それは別の機会にしましょう。
仮想マシンのプロビジョニングは
5分ほど待てば完了します。
便利な時代になったものですね。
ダッシュボードから
ホストを確認しておきます。
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を使ったので変な名前で
保存されていることに注意です。
「/辞辫迟」直下に解冻します。
解凍したPayaraの
実行フォルダに移動します。
GlassFishの場合、初期ドメインが
一つしかないためドメイン指定は不要でしたが、
Payaraではもう一つドメインがあるので
「domain1」を指定して起動します。
PayaraがGlassFishを使っていることが分かりますね。
管理コンソール用のポートが「4848」なので
azrueで仮想マシンを立てるときに
エンドポイントを設定していないとここで詰みます。
リモートデプロイを行うために、
管理ユーザのパスワードを変更します。
「admin」の初期パスワードは「」なので、
適当なパスワードを設定します。
リモートデプロイを行うために
HTTPS接続で管理コンソールに
アクセス出来るように設定します。
ドメインを再起动します。
ブラウザから4848ポートで
管理コンソールに接続できれば
設定完了です。
チームPJの作成から
Maven PJの作成まで
チームPJを作成します。
全てはそこから始まります。
今回はNetBeansを使って進めるので
Version controlはGitを選択する必要があります。
今回はチケット管理の話は割愛して、
リポジトリのクローンから行います。
クローン元の鲍搁尝をコピーしておきます。
NetBeans 8.0.2を使用します。
インストール時にJavaEEも
含めておく必要があります。
「チーム→骋颈迟→クローン」と选択します。
先ほどコピーした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」で設定を確定させます。
辫辞虫.虫尘濒が自动更新されたり…
奥别产.虫尘濒が自动生成されたり…
颈苍诲别虫.虫丑迟尘濒が自动生成されたり…
実行するとNetBeansが
GlassFishに自動でデプロイして
ブラウザ実行までしてくれます。
「index.html」は不要なため
忘れないうちに削除しておきます。
ここまでの変更をコミットします。
速攻でリモートにプッシュします。
CIでビルドのキューが
追加されます
ビルドは無事に
成功したようです。
VSOだけじゃないけれど
継続的デプロイも
「pom.xml」の<build>に
プラグインを追加します。
今回、追加するのは
「cargo-maven2-plugin」
です。
GlassFish4.x系の
リモートデプロイを
行うことが出来ます。
「ホストのURL」、「管理ユー
ザ名」、「パスワード」、「管
理用のポート」、「デプロイ先
のドメイン」を指定します。
続けてデプロイ対象の情報と
Webアプリケーションの
URLとなるコンテキスト
を指定します。
plugin用の依存性を追加します。
どんどん複雑になりますね。
ここまでの変更をコミットします。
辫耻蝉丑するとキューが追加されます。
後はビルドの成功を見届け…、
あれ?
「あ、これ練習用のサーバ名だ」
そう、CIは失敗するものです。
正常系だけをデモしてもダメなのです。
ワザトデスヨ、ホントウデスヨ。 という訳で気を取り直して、
失敗時に通知を飛ばすように
VSOの設定を追加します。
設定画面の
「Alerts」タブを
選択します。
「My Alerts」メニューから
「Build Alerts」を選択します。
「狈别飞」を选択します。
ビルド失敗通知の
テンプレートを選択します。
細かい設定もクエリを作成できますが
今回はデフォルトで作成します。
これでビルド失敗時にメールが来るはずです。
間違っていたホスト名を
正しく修正して
コミットして
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を確認します。
キチンとコンテンツが更新されています。
これで安心して終了できますね。

More Related Content

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