My External Storage

ソフトウェアエンジニア向けTips。Qiitaにもメモ

GitHubを使って3分でHPを公開する。

GitHubやばい、何がやばいってソース公開していいならWebサーバなくてもWebページ公開できる。 JavaScriptもちゃんと動いてる。(サーバ必要系はたぶん無理)

というわけで表題の件ですが、GitHubは主に2つの形式でWebサイトを公開できます。
テンプレサイト作るだけならgitコマンド叩いたり、ローカルにリポジトリ作る必要もありません。

  • ユーザーアカウントに対して紐付けられているWebページ
  • リポジトリごとのWebページ

ほとんどリンク先見てね状態ですが、毎回ググるのめんどくさいのでメモ書き。
GitHubアカウントもっているならば、3分かからないです。


ユーザーアカウントに対して紐付けられているWebページ。

yourself-account.github.io.gitリポジトリを作成することでWebページが公開できます。
こんな感じ。

f:id:budougumi0617:20140208223227p:plain

公式最強ということで、後はリンク先参照のこと。
http://pages.github.com/

上記URLには載っていないのですがテンプレサイトが作れます。
githubyourself-account.github.io.gitリポジトリの「setting」を開きます。
画面をスクロールすると、「Update your site」という項目があるので、隣の「Automatic Page Generator」というボタンをクリック

f:id:budougumi0617:20140208223230p:plain

あとは指示に従ってテンプレを選んだりすると完成します。
URLはhttp://yourself-account.github.io/となります。

例:
http://budougumi0617.github.io/

そのあとはcloneしてお好みのエディタで編集するなり、すげ替えちゃってください。
NetBeansの「新規プロジェクト」、「既存のリソースを利用するHTML5アプリケーション」で取り込み、編集、Chrome連携実行まで確認できました。


リポジトリごとのWebページ

今ある既存のリポジトリにもWebページを構成できます。
なので、ライブラリなどをGithubで公開した際はそのままそのリポジトリでWebページも作成出来ます。 おおざっぱに言うと、gh-pagesというブランチを切って、必要ファイルをそのブランチに突っ込めば、完成です。

以下は適当なindex.htmlを作成してとりあえず公開してみる方法。
前提はyourRepository/をルートとして、yourRepositoryリポジトリをcloneしている状態。 ある程度Git叩けることが条件

cd yourRepository/
git checkout --orphan gh-pages
git rm -rf . #これは別にやらなくてもいいかも
echo "My GitHub Page" > index.html
git add index.html
git commit -a -m "First pages commit"
git push origin gh-pages

あとは(若干タイムラグがあるらしいので、)一服してからhttp://yourself-account.github.io/yourRepositoryアクセスするだけ。

例:学習サイト見ながら作っただけのlocalStorageたたくメモ帳。jQueryが動くことは確認できた。
http://budougumi0617.github.io/html5NotePad/


以上で、GitHub上でWebページを公開する方法でした。
privateリポジトリでは作成できないなどの制約はありますが、pushするだけで実際に公開できるのは嬉しいですねー!
JavaScriptは動かないと思っていたので、それも嬉しい点です。


参考

GitHub Pages
http://pages.github.com/

GitHubでサイトを公開する方法
http://soudai1025.blogspot.jp/2012/07/github.html

GitHub の プロジェクトページ を 自動生成 & 公開 する 方法
http://garafu.blogspot.jp/2013/06/gihub.html

gh-pagesでGithubのプロジェクトをWEBページとして公開する方法
http://peroon.hatenablog.com/entry/2013/05/18/171144

html5NotePadページはドットインストールさんで学習させて頂きました。
ドットインストール:HTML5で作る「シンプルメモ帳」 (全8回)
http://dotinstall.com/lessons/memo_html5

MacでSublime Textを導入してみた[HTML5+JavaScript+Node.js+Markdown]

動機

MacVim、Mou、Kobitoなどいろいろ使っているが、イマイチぴんと来ない…
//Vim派閥だけど.vimrcを公私で共有している縛りがあるので、思ったカスタマイズができない。

なので今回はSublimeTextを導入してみました。
Node.js、Emmet利用できる点にちょっと興味しんしん。
会社の先輩、NetBeansでやるって言ってごめんなさいw
ファイル構成はちゃんとNetBeans用でプロジェクト作りますwww
だってIDEだとやっぱりスタバ()でドヤリングできないですやん。。。

インストール

まずは本体のインストール。今回は2.0.2
http://www.sublimetext.com/


パッケージ管理ソフトの導入

プラグインとでもいう拡張機能Packageを導入する。
View - Show Consoleを選択。

SublimeText2の場合は以下を記載。

import urllib2,os; pf='Package Control.sublime-package'; ipp = sublime.installed_packages_path(); os.makedirs( ipp ) if not os.path.exists(ipp) else None; urllib2.install_opener( urllib2.build_opener( urllib2.ProxyHandler( ))); open( os.path.join( ipp, pf), 'wb' ).write( urllib2.urlopen( 'http://sublime.wbond.net/' +pf.replace( ' ','%20' )).read()); print( 'Please restart Sublime Text to finish installation')

SublimeText3の場合は以下を記載。

import urllib.request,os; pf = 'Package Control.sublime-package'; ipp = sublime.installed_packages_path(); urllib.request.install_opener( urllib.request.build_opener( urllib.request.ProxyHandler()) ); open(os.path.join(ipp, pf), 'wb').write(urllib.request.urlopen( 'http://sublime.wbond.net/' + pf.replace(' ','%20')).read())

Packageのインストール

ここから本格的なカスタマイズ。
Command + Shift + pCommand Paletteが開く。
MacOSXAlfreadみたいなもん。installと入力するとInstall Packageが選択されるので、Enter。ひとつひとつ以下をインストールしていく。

プラグイン 内容
HTML5 左記の自動補完
CSS 左記の自動補完
jQuery 左記の自動補完
Bracket Highlighter 対応する括弧をハイライト
Browser Refresh Opt+Ctrl+rでブラウザ更新
SublimeLinter HTML,CSS,JSのリアルタイムエラー解析
Goto-CSS-Declaration Cmd+→CSSの同じ単語にジャンプ
AdvancedNewFile Cmd+Opt+Nでパス指定して新規ファイル作成
Emmet 略語書くとHTMLタグを展開してくれる。すげえ
Markdown Preview プレビュー用
Markdown Extended シンタックスハイライト用

設定ファイルの変更

アプリを立ち上げて設定ファイルを開く。#vimみたいに設定「ファイル」です。
Sublime text2 > Preference > Settings User (もしくはcommand + ,)

{
    //フォントサイズ
    "font_size": 13,
    //フォントタイプ
    "font-face": "Ricty",
    //行間
    "line_padding_top": 5,
    //タブサイズ
    "tab_size": 4,
    //空白の削除
    "trim_trailing_white_space_on_save": true,
    //タブやスペースなどの不過視文字を表示(お好みで)
    "draw_white_space": "all",
    //現在の選択行をハイライト表示(お好みで)
    "highlight_line":true,
    //自動改行
    "word_wrap": true
  //[Emmet]Tabキー展開の停止
  "disable_tab_abbreviations": true
   //[Emmet]日本語変換確定の文字消えを防ぐ
   "disable_formatted_linebreak": true
}

フォントタイプはお好きなように。
ちなみにMacRicty使いたいならこのHomebrewが楽ちん。
http://sanematsu.wordpress.com/2013/05/11/brew-install-ricty/
会社で食わされるスパゲティのために構築するんだったら、ゆたぽんのほうが優しい気持ちでコーディングできるからいい。


Emmetが展開するHTML5を変更する。

再起動後、Preferences → Package Settings → Emmet → Settings - Userと行ってファイルを開く。
以下のように変更

{
    "snippets": {
        "variables": {
            "lang": "ja",
            "locale": "ja-JP",
            "charset": "UTF-8",
            "indentation": "\t",
            "newline": "\n"
        }
    }
}   

新規ファイルでhtml:5と入力後、Ctrl+eを入力
自動展開されたhtmlタグにlang="ja"があってたら成功(設定ファイル更新後は再起動が必要かも)

<!doctype html>
<html lang="ja">
<head>
   <meta charset="UTF-8">
   <title>Document</title>
</head>
<body>
    
</body>
</html>

Node.jsと連携する

まずはNode.jsのインストール。
http://nodejs.org/
MacbookAir(mid13)なら.pkgファイル展開するだけでいけるはず。
Terminalを叩いて以下が出ればOK

Airlocal:git budougumi0617$ node -v
v0.10.25

デフォルトの格納先はこの辺。

Airlocal:git budougumi0617$ ls /usr/local/bin/node
/usr/local/bin/node
Airlocal:git budougumi0617$ ls /usr/local/bin/npm
/usr/local/bin/npm

あとはsublimeTextがビルドするさいにNode.jsを使うようにするだけ。
Tools>Build System>New Build Systemで新しいビルド用設定ファイルを開く。
C/C++っぽい設定が書いてあるので、以下に変更。
node.sublime-buildなんて名前にすれば、Build Systemに"node"が追加されているので指定。

{
    "cmd": ["node","$file","file_base_name"],
    "working_dir":"${project_path:${folder}}",
    "selector":"*.js"
}

Cmd+Opt+Ntest.jsファイル作成。

console.log("Run JavaScript in Sublime Text!");

Cmd+Bでコンソールが開いて出力されれば成功。


Markdownにも対応する。

ついでにMarkdownも。
.mdファイルを開きながら、View>Syntax>Open all with current extension asMarkdown Extendedを対応付ける。
Preferences>Color Scheme>Monokai Extended でどちらか好きな色設定にに変更。


最後

これでドヤリングできる準備はできました。雪が降っていようが今すぐスタバへGO!
ただし、ハローワールドなんかかいていたら失笑されるかもね。。。

※この記事は2014年02月08日に作成されました。
参考:東京に大雪警報 23区で13年ぶり

あ、vim化はしないです。バインディングは結構追加しているので。。。

参考サイト

今回は以下のサイトを参考に導入させて頂きました!!

Sublime Text 2ってエディタがすごくイイ。Dreamweaverから乗り換えた時の初期設定とか使い方とかをメモ
Sublime Text 2でフォントを設定する方法
Sublime Text 2 : Emmet プラグインが出力する HTML の言語を修正する
Sublime Textで新規ファイルをスムーズに作る方法
Sublime TextでJavaScriptを実行する
Macでgithub markdownのpreviewはsublime text 3がよさそう

DevOps時代のテスト自動化カンファレンス 冬の陣 に行ってきた

DevOps時代のテスト自動化カンファレンス 冬の陣 に行ってきた

日時:2014年01月28日 13:00-17:20
場所:秋葉原 富士ソフトアキバプラザ5Fホール
主催:アイティメディア株式会社@IT編集部

https://itmedia.smartseminar.jp/public/seminar/view/572


まとめ

あまりメモ書きの精度がよくないので、まず先にまとめ。

所感

講演された4社中3社が自動化支援ツールのデベロッパー側だったため、自社の導入事例というよりも顧客の自動化に携わってきた経験、また自社製品を利用したプロセス最適化の提案例などコンサル的な視点な内容を聞くことができた。
どの会社の方も自動化を導入することでで得たい最終的な効果を洗い出す長期的な視野と、プロセスとして定着させること(属人化しないこと)の継続性を説いていた。
確かに「Jenkins入れれば最適化できる!」「とりあえず静的解析するようにしたから品質が改善する!」というようななんとなくでの利用が多かったため、単純な自動化スキルよりも改善対象となるプロセスの詳細な問題分析と深い理解が重要だと感じた。

自動化成功の秘訣

目的の明確化、プロセスとしての定着がカギとなる。

目的の明確化

  • 現在の課題(欠陥検出率なのか、リグレッション工数、スモーク工数なのか) *欠陥検出率の向上を目的としても本質的にはテストケースの低品質なので自動化しても効果がない。
  • 退屈かつ単純なエラーをなくす
  • システムの信頼度を上げたい

プロセス化に向けたテスト自動化チームの立ち上げ+プロジェクトリーダーのコミット
* 自動化の専門家を育成(ツール+専門家)
* メンテナンスできるチーム
* 長期視点で計画を実行できるチーム

テスト工程にかぎらず自動化を行う上で一番重要となるのが、「自動化を導入してどのような効果が得られるのか・得たいのか」を明確する重要性を指摘されていた。
アジャイル」、「継続的デリバリー」などのように「自動化」も往々にしてバズワードとなる危険性が極めて高い。
「何のためにやるのか」をリードできる人がいないとつまづく自動化することでビジネスのどこにメリットが生まれるのかを明確にしないといけない。
例えば、「テストに時間がかかっている」ならば何が原因で時間がかかっているのか。 そのようなことまで踏み込んでいかないとツールは選べない。

ツールデベロッパーからすると、 ユーザーがツールの導入を目的にしている場合が多い。ロードマップとして、ツールを利用して何を実現したいかをわかっていないことが多い。

そして、一人が自動化を推進・実施しても意味が無い。プロセスにならない個人依存だといずれ廃れてしまう

失敗しないテストツール選びとは

ボトムアップで自動化をすると予算ができない。だからまずOSSで始めるのはいいアプローチだと思う。プロジェクトのプロセスを全て網羅、定着支援をできるのが、 商用ツールのメリット。
2,3人程度の開発テーマならOSSで十分。 しかしメンバーが10人以上を超える場合や社内標準化を視野に入れると運用コストが増大、商用ツールを利用したほうが(有償サポートがあったほうが)低コストになることが多い。定着支援など総合的なサービスはOSSには無い商用ツールの大きなメリット。

自動化に適したテストの選択

  • 複数回行うテスト(回帰テスト
  • クロスブラウザテスト
  • 頻繁に仕様が変更されない機能のテスト
  • データエントリ系のテスト(入力項目やデータ量が多い)
  • パッチリリース時に定期的に行うテスト(リグレッション)
  • 演算や計算を伴うテスト(機能テスト。SAPのログインテスト)

以下は各講演のメモ。散文注意。


リクルートSUUMO流DevOpsの捉え方と実践

IT企画部 内田明徳

HWベンダー、SIerベンチャーを経験。
リクルートでは、じゃらん・ゼクシィ・SUUMOなど担当。戦後処理のタイミングでアサインされることが多かった。


DevOpsはバズワード。ITサービスのリリースサイクルを加速させる。

落とし穴:開発・運用がともにスピード偏重になる。しかし品質も重要である。

サービスがダウンしてはいけない。セキュリティの脅威も身近になっている。
品質要求が高いシステムにDevOpsは必要ない…?/品質要求が高いシステムにはDevOpsは適用できない?

落とし穴:ツールの導入自体が目的化する

どのツールを選ぶか<いつ 何のために導入するのか
Solutionはプロダクトアクトではない、課題解決を提案しなければいけない。
課題は環境によって千差万別である。
何の課題を解決するのか?課題の「設定」が重要である。


  • エッセンス1:異なる目的をもつ組織間のコラボレーション
  • エッセンス2:全ての部門でビジネスの変化に敏感になる
  • エッセンス3:開発・運用の見直し

SUUMO流の捉え方

OpsDev。Ops先行ではないのか
OOD。運用を先に考えるべきではないのか

背景:住まいカンパニーの成り立ち

リクルートが事業別に分社化。「住宅事業」部分が住まいカンパニー。
提供サービスはスーモ。住まい探しブランドでは国内最高の認知度。
スマホ・Web・フリーペーパー、書籍、展示場などで情報を提供している。
ネット利用者は930万UU。

リクルートのビジネスモデルはスーモに限らずマッチングサービス。


複雑化したシステム構造

  • 情報誌時代は品質重視
  • システム統合・拡張を繰り返し、ぐちゃぐちゃ

着任時のIT組織

請負


開発と運用が曖昧
品質よりもスピード重視

だが実態は運用軽視


カイゼンに対する意識が向上し、やっと次のステージに。

トレンド変化1:ITの範囲の拡大。
トレンド変化2:クラウドの浸透
保守のサポート切れに伴う更改が減った
トレンド変化3:小さく出して磨く
世の中からフィードバックを得る

スピードと品質+変化への対応力が必要!

次世代IT戦略
新標準の作成と移行

xyz構想

既存xからスピード重視のYは継続的デリバリー、クラウド,
品質重視のZはロードマップ開発、おんプレ

サービスライフサイクルマネジメント
計画的に作り直し、徐々に個別ー>全体最適に進化させる。

エンハンスを超えたあとは安定保守のためルールの定着。

アナリスト機能の強化

ビジネス目的の分析により、「小さな作り物」で実現する。
自前システムと外部技術の使い分けを行う。

作り方の憲法(Rule of Dev)は出来た。
どうルールを維持、継続していくか(Ops

Opsの変質に対応する。

Devの現場力学としてのDo。
OpsとしてのCheck.Act。

Dev主体からOpsのありきへ

重要なのはOpsの地位の見直し。Planの際に運用・保守をプランニングすることが大事。

運用設計の進化系

リリース後「どう過ごすのか」が重要になってくるのではないか。
運用というよりも活用といったほうが良い。

DevOpsがくれた気付き

それは文化と向き合うこと。
アメリカのセミナーではカルチャーなどに向き合う内容があった。
日本でもそれは重要だと思われる。

ビジネス変化、IT文化に対応するためにプロセス、組織、構造、ツールなどがある。
まず何に対応するために導入するのかを考えなければならない。

スーモでは

スピード・品質を進化させつために。
ビジネスの変化に対応するために。

DevもOpsも仕組みの背景を理解し一緒に磨く。

個別に工夫する・迷う時間を減らし、お互いクリエイティブな仕事に専念できる。
それがイノベーションの源泉になる。

各社で作りたい文化は異なる。
What, When Whyを議論し、仮説検証するプロセスを回すことで文化は作れる・変えられる。

→DevOpsもAgileに作れる!!



DevOpsが求めるスピードと品質を両立するためのテスト戦略はテスト戦略はどうあるべきか。

日本IBM株式会社 ソフトウェア事業 ラショナル事業部

ソフトウェア・ビジネスにおけるDevOpsの役割

DevOpsの必要性

ビジネスの目標を達成するためにDevOpsが必要。。。だがなぜDevOpsなのか?

アジャイル」より「DevOps」はお客様から運用・本番までをカバーできる。
迅速に開発する。から迅速に開発・デリバリーする。へ。

DevOpsによるソフトウェアライフサイクル

デリバリーにより、実際にアプリを使った上でのフィードバックが得られる。 フィードバックにもとづき、私情が求めるものを的確にとらえたアプリの開発・運用ができる

DevOpsにおけるテストに求められるものと課題

DevOpsでは以下の問題が顕著になる。
ソフトウェアの品質担保:ビルド数が急増、テストの増大・環境の多様化。結果の評価
テストスピードや効率:計画通りのテスト実施、テスト環境の順番待ち、リリースサービスが完成する前の実施。
テスト資産の効率的な作成・メンテナンス、効率的なテスト環境構築・運用

DevOps時代のテストはどうあるべきか

以下に数多くのビルドをテストするか

効率的なテスト自動化

  • 実際にテストを実施し、その操作記録からテストスクリプトを自動生成
  • 目的に合わせてテストスクリプトを編集・拡張し自動実行
多様化する環境にいかに対応するか。

環境のバリエーションテストの効率化

  • デバイス・OS・ミドルウェアが異なる環境下でのテストを効率的に自動化
テストの待ち時間をいかに短縮できるか

リモートシステム上のサービスの仮想化 * 開発者が自由にテストできる環境の提供。エミュレーション環境の作成。 * 中間層、基幹システム上のサービスの完成前でもテストが可能に。アプリケーション品質向上の早期化で開発期間も短縮できる。

単体テストでの品質が向上する。結合時の障害を削減できる。

テスト資産をいかに効率よく作成・メンテできるのか
  • 使いやすい統合開発環境上でコーディングなしでサービスを仮想化。
  • 実際のトランザクションを記録してスタブを作成→効率的なリグレッションテストの実施。
  • インた~フェース定義ファイルからスタブを作成→新機能テストにも迅速に対応
  • 利用可能なリソースを最大限に活用。
  • テストに利用可能な実システムとスタブを併用し、必要なデータだけを追加作成
  • 実システムによるテストが必要な状況にも柔軟に対応可能。

仮想化システムをはさみ、クライアント側に意識させずに最適な実システム・スタブの切り替えを行う。

テスト環境構築・運用をいかに効率化できるのか
  • テストのための設定変更を最小限に。 同じ環境設定えテスト資産作成とテスト実行が可能
    proxy設定の変更のみで、スタブのOn/offを簡単に切り替え。
テストにおける課題への対応策一覧。

ソフトウェアの品質担保
数多くのビルドをいかにテストするか?
→効率的なテスト自動化
多様化する環境にいかに対応するか?
→環境のバリエーションテストの効率化(テスト自動化)
テストのスピードや効率の向上
テストの待ち時間をいかに短縮できるか?
→リモートシステム上のサービスの仮想化
テスト資産をいかに効率よく作成・メンテできるか?
→コーディングなしでのサービスの仮想化
→利用可能なテストリソースを最大限に活用(サービスの仮想化)
テスト環境構築・運用をいかに効率化できるか?
→最低限の設定変更によりテスト環境構築・運用時のミスを防止(サービスの仮想化)

DevOps実践のためのテスト戦略

DevOpsのテストにおける課題は「自動化」「サービスの仮想化」により迅速・継続的に対応

ただし。。。
効果が局所的になりがち
リリースが目指すビジネス目標とのつながりが不明瞭。

リリースされるアプリケーションが必要な品質を保つには?
ラショナル使いましょう!

 テストの目的

目的は「アプリケーションがビジネス目標を達成できる品質を保つ」ことの確認
その達成のてmにテスト計画を立案しつつ、チームで共有・実行していく。

テスト計画の立案・共有実行を支援する環境の構築
自動化だけでなく、テストの目的をチームでコミットメントできるようなソフトが必要
その計画を達成するために必要なテストケースの作成、スクリプトの実行、テスト結果のレポート

手動テストもまとめて管理するなど、ビジネス目標を達成するために一元化して全てを管理するソフトウェア

DevOpsがもたらす価値

ライフサイクル全体にDevOpsを拡張することで全体視点からのギャップとボトルネックを解消。
デリバリの加速
フィードバックに迅速・継続的に対応
QCDの最適化。
ソフトウェアライフサイクル全般に渡る「人・文化



 コベリティ社内開発チームが挑むテスト自動化と技術革新

コベリティジャパン株式会社

リリースプロセス

一般的なリリースプロセス * 半年おきのリリース * 3ヶ月に次期リリース計画 * リリース直線の6週間の”バードニング”サイクル

リリースを実行するプロセス

  • アジャイルプロセス
  • 部門横断的なすくらむチーム
  • 2週間のスプリント
  • メールまたは対面での日時スタンド・アップ
  • JIRAとPivotalTrackerを介した進捗管理
  • Bugzillaによるバグ管理
  • Jenkins-CIによる継続的統合
  • 週1回のステータスミーティング  
    • リリースハードニングでは週に3回

フロントエンドはsalesforceが対応。

デベロップメントテスト

静的解析 手戻りを激減させるテクノロジー

コベリティの製品リリースプロセス

2年前の状況

製品構造概要
インプットされたコードをフロントエンドMdでパースする。
コンパイル後は解析Mdでエミュレーション。
コネクタ(UI)でユーザーに情報提供

2年前のテストアプローチ
フロントエンドと解析のコンポーネントは自動化されたテストでテストされていた。
UI部分が手動テストで行われていた。

  • QAプロセスは東ヨーロッパにアウトソース
    • 伝統的なQAスキル、開発スキルはわずかもしくは皆無
    • 時差
    • 言語の壁

矯正への最初の試み

QAと開発の間の境界を取り除く →組織的+時間的

2011初頭に組織を再編 →開発しながらテストする。ように設定

しかし、結果は期待はずれだった

QAチームはプログラミングに関してトレーニングされておらず、 自動テストを開発するのが困難であった。 時差と言語の壁が存続していた

抜本的な改革 ー人

東欧からカナダ、カルガリーに移動。 →時差は1時間 →サンフランシスから2.5時間のフライト →言語の壁がない

抜本的な改革 ープロセス

テストの自動化に集中する

自動化されたテストにより2つの効果 フィーチャーに期待する挙動の成文化 機能が完成した後のリグレッションの検知

テスト自動化の進捗

UI画面に関しては改造したSelleniumで対応

インフラ

短いテストのほとんどはJenkins上のビルドプロセスの一部として実行 物理100以上、仮想OS200以上でテスト 自社製品を利用して、クリーンコードを維持して自動化

なぜ自動化が進んだのか?

進捗を計測する良い指標が無いことに気づいた →カバレッジはテスト工数に関しては良い指標ではなかった。 →新機能のコードは全体のカバレッジで把握しにくい →開発しながらテストする。ことを牽引する計測可能な基準の欠如

以下のコードに着目した自動テスト開発をガイドする ・新規コード ・リスクの高い部分を特に識別 ・関連の無いコードを除外

コードカバレッジに対するチャレンジ

80%から100%はなかなか進まない

実験

新規のコードと影響を受けるコードにフォーカスしてテストの指標を立てる。 上記の基準だと未テストコードの0.2%しか対象はなかった。

自動テスト開発支援ツール

変更の影響を静的解析ツールの応用で調査。 →優先的にテストすべき箇所を特定

変更の影響解析

社内での経験 ーケーススタディ

1人週で29件のテストを追加→19件のバグを発見できた。 テストを作成した結果、不具合がどれくらい見つかったのかが大事。

インパクト解析を取り入れたテスト自動化ワークフロー

コーディング ユニットテストの作成 コードを解析+危険箇所にテストを行っているかも確認。 単体レベルで保証。 コードの追加・変更のため、新しいテストが必要かチェック。

まとめ

  • クリーンなコードでなければ自動化できない。
  • 全てを自動化するのは非現実的
  • 高リスク箇所を見極めよ

テスト自動化を成功させる秘訣とは

マイクロフォーカス株式会社

マイクロフォーカス社沿革

COBOLコンパイル会社ではトップシェア

現在のITプロジェクトが抱える課題

とくに厳しいのは以下

  • 工数の40%が手戻りの作業

これを削減できれば大きなメリットになる。

失敗原因ベスト5

  • 顧客のプロジェクトへの関与不足
  • 要件定義の不備
  • プロジェクトスコープの変化に対応できない
  • 変更管理システムの不在
  • テストの不備

テスト自動化の動向およびそのメリット

ブラックボックステストにフォーカス

なぜ自動化なのか? 人手によるテストでは全てのテストを網羅できない。

現在ではテスト回数が多ければ多いほど自動化が必要。今後は必須になる。

テスト自動化を行うメリット

テスト自動化は半年後、1年後を見る必要が出てくる。 未来を見据えるテストが実施できる

テスト自動化によるコスト削減

同じテストが4回以上の場合テスト自動化によるコストが削減される。 10回テストが行われるプロジェクトでは、トータル約45%の工数削減

テスト自動化の失敗ケース

「方法」での失敗

  • リグレッションを100%を自動化→3割程度で十分(正常系は100%)
  • 手動テストを再現しようとする→スクリプトに頼ることになり変更・メンテに弱くなる

体制」の失敗

  • 担当者の技術不足
  • プロジェクト化され、プロセス化に失敗

コードが読めない人がアサインされて失敗

NTTのCOE(自動化専門部隊)

「ツールの選択」の失敗

  • ベンダー中心の選択

テスト自動化を成功させる秘訣

目的

  • 現在の課題(欠陥検出率なのか、リグレッション工数、スモーク工数なのか) 欠陥検出率の向上を目的としても。。。本質的にはテストケースの低品質なので自動化しても効果がない。
  • 退屈かつ単純なエラーをなくす
  • システムの信頼度を上げたい

テスト自動化チーム+プロジェクトリーダーのコミット * 自動化の専門家を育成(ツール+専門家) * メンテナンスできるチーム * 長期してんで計画を実行できるチーム

一人がやっても意味が無い。プロセスにならないと個人依存だといずれ廃れてしまう

適したテストの選択

  • 複数回行うテスト(回帰テスト
  • クロスブラウザテスト
  • 頻繁に仕様が変更されない機能のテスト
  • データエントリ系のテスト(入力項目やデータ量が多い)
  • パッチリリース時に定期的に行うテスト(リグレッション)
  • 演算や計算を伴うテスト(機能テスト。SAPのログインテスト)

自動化に際し考え方を切り替える

手動テストは、テスト手順書にもとづいてシナリオを最初から最後まで実行し、 証跡を取得しながら進めていく →いわゆる縦割のテストなので横のつながり(処理)は考えなくて良い

自動テストは、スクリプトの記録工数や再利用性を考えて 共通の画面処理をまとめてスクリプト化する。 →横のつながりを意識してスクリプトをモジュール化し、 それを呼び出すことでスクリプト作成工数を削減できる。

自動化をプロセス化する

プロジェクト化する問題点
  • 属人化するとうまくいかない
  • 終わりがない
  • 開発との連携はテスト自動化の重要な要素
開発プロセスの中に取り入れる。
  • GUIアプリ作成時に標準オブジェクトを使用する
  • テストケース作成時に手動、自動が判断できる専門家が必要
  • テストケースをモジュール化
  • スクリプト作成は、オフショア等を活用
  • スクリプトを個人管理させずに共有化する。

テスト・ツールの選択

事前評価は必ず行う
テスト自動化ツールは必ずサポートが必要
  • 無償ツールなら自社で解決する必要がある
  • 有償ツールなら、購入後のテクニカルサポート、FAQサイトが利用可能
  • ツールのトレーニングは必須

標準化することになると無償ツールでは対応できない (サポートが必要、トレーニングが必要、全員が一定のスキルを持っていない)

大手企業で自動化を標準化しているところにSelleniumを利用している企業はない。

テスト自動化を成功に導くマイクロフォーカス製品

宣伝

成功事例の紹介ページ

セミナーの案内



パネルディスカッション

テスト自動化にどう取り組むのか

社内文化がない場合は?回答:う

最初は属人化していた。 まずは見える化。市場障害などが漏れた原因分析が大事。 クリエイティブな時間を増やす・品質の統一をできる 属人化とは個人に基準が依存していた、個別最適となっていた機能の知識が属人化。 自動化で「どれくらいの品質でこういうテストの数が。。。」というのが標準が揃ってきた。

体制の重要性・体制化のアドバイス その他3名 まずなぜ自動化をする必要があるのかを明らかにすること。 「何のためにやるのか」をリードできる人がいないとつまづく。 体制の前の意識を持てているかが大事。 自動化することでビジネスのどこにメリットが生まれるのかを明確にしないといけない。

中がどのような要求で出来ているのかを理解していること。 時間がかかる、先を見据えた目標が大事。体制づくり、準備に時間がかかることを予め覚悟しておかないといけない。

だれが始めるのか?運用に入ってからが効果がでてくる。費用対効果がでると実感が出てくる。 NTTは1プロジェクトに4000万かけて自動化した。でも成功だった。 回帰テストが16回以上行われることがわかっていたので、開発フェーズから着手した。

自動化するための工数、コストはどうやってクリアしたのか? コスト効果を計上しても架空の数字になってくことが多い。 まず開発・運用が効果を実感できることが大事。 まず無償ツールなどを利用して「小さく始める」ことで効果を確かめる。

どこをどれだけ自動化すればいいのか? スーモは2つのポイントがあった。 構造がよく似た特集ページを毎回作るので、そこにsereniumを利用している。 APIの作りから構造化して自動化している。

自動化している人は専門の人がやっている。 マイクロ テスト自動化は専門部隊じゃなくてもできると思う。 開発者がプロセスに自動化を埋め込むことができれば新しいアプローチだと思う。 コベリティ バグを見つけながら。。。というアプローチなので、 毎回レポートを参考にしながらターゲットを絞って行う。

IBMの場合の自動化するポイント データ駆動型はやるべき。コピペミス、手間を考えると。 プラットフォームが多様化しているような製品の場合は自動化がよく効く

バグを指摘されてもPGに響かないような社内文化とは?

バグはかならず入る。ホントはテスター、テストに感謝すべき。 客観的に見る風土、バグと個人を分けて考える風土が大事。 スーモ 開発者がコードを書きたくても本番でバグ多発していて障害対応でいっぱいいっぱいだった。 世の中に出す前に障害を見つけたほうがいい、テストで防げたほうが良いという考え・文化が生まれた。 QA部隊の受け入れテストの基準がうまくできていない。そこも踏み込んで標準化したい。

まずテストケースが重要。 開発者がケースを作成すると必ず漏れが出る。なぜならば要件、外部設計、UIを理解している開発者はあまりいない ファンクションに対しては開発者はできるが、受け入れテストは全体理解をしている人がケースを作成しなければならない。 要件が漏れている、上流設計が甘いと品質が悪くなる

要件を理解しているだけではだめ、どういう実装がされてるか理解できていないと
企画がケース作っても異常系にも漏れがでる。
要件ベースではなく、仕様ベースになっているとその要件と仕様の間に漏れが生まれる。

無料のツールではダメなのか?

目的や状況にもよる。
スタートアップや少人数では無償でいいと思う。
OSSのほうがリッチな機能があるのも事実。
ただ、ロードマップを考えた時には有償のほうが。。。?
定着支援など総合的なサービスは無償ではできない。

IBMが現場に行くと2タイプいる
* 破綻しかけているので教育・コンサル的な部分を含めて導入したい
* 導入考えているので比較したい。

コベリティが現場に行くと。。。
* 静的解析はあまり無償ツールの敵はいない。
性能がいいならば無料でも使いたいだろう。
有償がいいのは、管理面。OSSだとあまり考えられていない。ポイントソリューション
全体のワークフローを考えたときに運用できるのはやはり商用。。。

フォーカスの場合
運用コスト。2,3人ならOSSで十分。
10−以上を超えると運用コストが一変する。

スーモの場合は
すぐに商用をいれても現場が意味をわからない。
スモールで導入して、商用をほしいというようなニーズが現場に出てからでもいいと思う。
基本的OSSの使い方はエバンジェリストが頑張ってくれてる

失敗しないテストツール選びとは

ボトムアップで自動化をすると予算ができない。
だからまずOSSで始めるのはいいアプローチだと思う。
プロジェクトのプロセスを全て網羅、定着支援をできるのが、
商用ツールのメリット。

ツールが定着しないパターン
トップダウン、無理やり使っている。現場がの声のでかい人がいうから使う。という状態だと失敗する

現場がしっかりとツールを使う目的、解決したい目的があれば成功する。
道具を導入すること、テスト自動化が目的になってはいけない。

例えば、「テストに時間がかかっている」ならば何が原因で時間がかかっているのか。
そのようなことまで踏み込んでいかないとツールを選べない。

ツールデベロッパーからすると、
ユーザーがツールの導入を目的にしている場合が多い。
ロードマップとしてツールを利用して何を実現したいかをわかっていないことが多い。

Q&A

DevOpsとクラウドスマートデバイスの関連性は?
クラウドで運用の寿命が長くなっている。
スマートデバイスによって多様化が必要。
そうなると変化につよいDevOpsが関わってくる。

インフラエンジニアがクリエイティブにできるのもDevOps。(chefとかクラウドとかで)

DevOpsが必要な時代になったのは変化が早い、スピードが早いクラウドスマートデバイス
ただし、クラウドスマートデバイスでなくてもDevOpsはできるので。。。

Selenumを使うときはWebドライバで、IDEで使っている人が多いのか?
コベリティ社内ではコーディングしている
スーモもコーディングしている。
ってかこれからの時代QA区の人もコーディングスキル無いとやばいよー

導入するとき
全面的にプロセスにかかわってくるので3年以上の長期的なプロセスを経る。

ドットインストールでHTML5の勉強を始めてみた。

HTML5の知識が必要となったので、dotInstallを用いて学習を行う。
まずは開発環境の整備から。今回作成した開発環境は以下のとおり。

NetBeansを選んだ理由はHTML5JavaFXを安定して利用できそうだから。また、同様の理由でNetBeasのインストールではJavaEEのプリセットを選択した。


開発環境作成の手順

下記リンク先の情報を参考にNetbeansをインストール
このとき、予めローカルにgitリポジトリがあると、プロジェクトをそのまま構成管理ツール上で利用できる。

HTML5の製作環境としてNetBeans IDEを使ってみる
HTML5アプリケーションの開始


動作確認

環境構築後は下記のコードを写経して、簡単にフォームを作成。

HTML5 #01 メモ帳の画面を作る

空のHTML5プロジェクトを作ったならば、以下のようなindex.htmlを作成する。 Webブラウザでフォームを動作を確認して、完成。 NetBeansではChromeを利用してリアルタイムプレビューを行うことができた。

<!DOCTYPE html>
<!--
To change this license header, choose License Headers in Project Properties.
To change this template file, choose Tools | Templates
and open the template in the editor.
-->
<html lang="ja">
    <head>
        <title>HTML5を使ったメモ帳</title>
        <meta charset="UTF-8">
        <meta name="viewport" content="width=device-width">
    </head>
    <body>
        <h1>メモ帳</h1>
        <textarea id="memo" rows="10" cols="40" name="40"></textarea>
        <p><input type="button" id="save" value="Save"> <input type="button" id="clear" value="Clear">
        </p>
    </body>
</html>

このドットインストールは全8回なので、適宜続きを行ってみる。

C++でプログラム内で変数名を取得したい

C++で変数名を取得する。
実行時に構造体などの変数名を知りたかったため。

#include <iostream>
#include <stdio.h>
#include <string.h>

// For get variable name.
#define TO_STRING(VariableName) # VariableName
static const int MAXLENGTH = 256;

typedef struct {
    char charArray[MAXLENGTH];
} FooStructure;

typedef struct {
    int value;
    FooStructure fooSt;
    FooStructure *pFooSt;
} TestMacroStructure;

int main(int argc, char *argv[]) {
    int value = 3;

    // Get variable name
    std::string str = TO_STRING(value);

    // Display variable name.
    std::cout << str << std::endl;
    TestMacroStructure checkMacro;
    std::cout << TO_STRING( checkMacro.value) << std::endl;
    std::cout << TO_STRING( checkMacro.fooSt) << std::endl;
    std::cout << TO_STRING( checkMacro.fooSt.charArray) << std::endl;
    std::cout << TO_STRING( checkMacro.pFooSt->charArray) << std::endl;


    return 0;
} 

make後の出力結果は以下の通り。

budougumi0617@SERVER:~/> ./getVariableName
value
checkMacro.value
checkMacro.fooSt
checkMacro.fooSt.charArray
checkMacro.pFooSt->charArray

参考URL

変数名取得マクロ
http://faithandbrave.hateblo.jp/entry/20071116/1195228361

LPICレベル1技術解説無料セミナーを受けてきた

LPICレベル1技術解説無料セミナー

開催日時:2014/01/19(日) 13:30〜16:30
開催場所:AP浜松町
対象者:Linuxをこれから学習する人、体系的にLinuxを学習したい人。LPIC101ベース


所感

ひと通りLinuxは利用できるが、独学だったため、自分の実力を確認するため受講。
講師が「SSHとか知ってますかー?」とか聞いちゃうような初心者を対象にしたセミナー   
ちょっとしたコマンドオプションのTipsは得られたが、VMなどでLinuxを立ち上げたことがある人はほとんど聞く必要がないセミナーだった。
LPIC1ならばLinux未経験者でも80時間ほどの学習で取得できるらしい。
上位のLPICを取得前に一度受けておいても良いかもしれない。


LPICレベル1の難易度

1ヶ月程度の勉強で合格可能。
文系でPC初心者の人でも101,102それぞれ36時間程度ずつの勉強で合格できる。


LIPC(Linux技術者認定試験)の概要

Linux技術者の将来性

需要はあるが、技術者は少ない。

LPICとは

  • オープンソースであること
  • ベンダーに依存しないこと
  • 本質的、広範囲の問題

LPIC2,3に関しては試験範囲がだいぶ変更されるので注意すること。

101試験の出題範囲


Linuxの構成、基本操作

演習環境

Windows上にVMwareCentOSUbuntuの2つのOSを準備
CentOS:RedHat
Ubuntu:Debian

Linuxの大きな特徴

オープンソースのOS

Linuxディストリビューションの構成

本来はLinuxとはLinuxカーネルのこと。しかしOSとして機能するにはシェルやカーネルモジュールが必要。これらを全て含めてパッケージ化された「ディストリビューション」として提供される。

Linuxディストリビューションの種類

日本はRedHat系のディストリビューションが圧倒的に多い。官公庁はUbuntuなども多い。
RHEL有償だがバックエンドでサポートしてもらえるので利用が多い。
もし、スキルがあってサポートがいらないならばOSとしてまったくクローンのCentOSでよい。

Linuxの構成と101出題範囲

各対応は以下のとおり。広く浅くフォローされている。
主題101:ハードウェア 管理
主題102:ライブラリ・アプリケーション
主題103:コマンド・プロセス管理・データ入出力管理
主題104:ファイルシステム管理

カーネル・シェルの役割

カーネルはLinuxOSの中核となるプログラム。カーネル機械語しか理解できないので、シェルでユーザーとカーネルを仲介する。

マルチユーザーシステム

Linuxは複数のユーザーで同時に利用することができる。SSHによるリモートログインが当初から念頭に置かれていた。

rootと一般ユーザー

rootはひとつのLinuxにひとつのみ。

ユーザーインターフェース

LinuxのUIはCUIのみで利用可能。ただし、GUIはマウス操作ができること、GUIのために100以上のアプリをインストールする必要があること、そのため、CUIのコマンド実行で操作することが多い。

ログインの実行(CUIランレベル3

ログインの実行(GUIランレベル5

ランレベルとは?

OSの起動レベル
0 停止
1 シングルユーザーモード(メンテモード)
2 マルチユーザーモードCUIログイン、NFSなし)
3 マルチユーザーモードCUIログイン)
5 マルチユーザーモードGUIログイン)
6 再起動

変更コマンドは以下のとおり

$init 3
$telinit 3

ディレクトリとは

Windowsではフォルダといいますが、Linuxではディレクトリという

ROOTディレクトリ

ディレクトリツリーの頂点。 また、トップディレクトリにはhomevarなどがあり、それぞれの意味はLPICでも出題される。

  • homeは一般ユーザのディレクトリ
  • etcが設定ファイルの場所
    など

ホームディレクトリ

ユーザ毎に与えられるディレクトリで、ログイン直後のカレントディレクトリ。


101試験範囲よりポイント解説

コマンドプロンプト

管理者ユーザの場合はシャープが出る。

#

一般ユーザの場合はドルマークが出る。

$

コマンドの基本構文

  • 半角英数字
  • コマンド、オプション、引数の間は半角スペースで空ける
  • 大文字小文字を区別する
  • 入力の最後にエンターを押す
  • オプションにはハイフンをつける

基本コマンド

~...は基本中の基本なので、しっかり覚えておくこと。
rootでログイン、lpicユーザーが存在した場合、~lpicだと/home/lpicを表す。~/lpicは /root/lpicになるので注意する。

マニュアルの参照

manコマンドでマニュアルを見ることができる。試験的には1章、5章、8章をよく読んでおくこと。

passwdなどはコマンドもファイルも存在する。ファイルのマニュアルを参照したい場合はman 5 passwdと入力すると良い。


ディレクトリの配置

/tmpは一時的ファイル保管のディレクトリ。全てのユーザが読み書きできる。
/procはメモリの中にある仮想ファイルを表示している。

パスの概念

ファイルやディレクトリへたどり着く経路をパスという。
絶対パス/から開始される。LPICの問題では記述問題もあるので、/を忘れないようにしておくこと。 相対パスはカレントディレクトリを起点としたパス。

基本的なコマンド(2)

mkdirコマンドで親ディレクトリもまとめて作成したい場合はmkdir -p parerent/tagret-pオプションを指定する。

基本的なコマンド(3)

cpコマンドの説明。

基本的なコマンド(4)

mvは名前変更という使い方もできる。

ファイル閲覧コマンド

cat, less, head,tailなど。
head,tailのデフォルトは10行。-fコマンドを利用することでリアルタイム表示をすることができる。


viの使い方

一般的な使い方なので割愛。ただ、viの使用方法についてもLPICの試験に出るので覚えること。

プロセスとは

コマンドやプログラムファイルを実行すると、プログラムがメモリに読み込まれ、プロセスにはID(PID)がつき、システム内で識別される。
サーバ機能を担う常駐型のプログラムは「デーモン」と呼ばれる。

プロセス監視コマンド

psコマンド。システム全体のプロセスを監視する際は他のユーザが実行したプロセスも監視する必要があるため、auxなどのオプションを必ずつける。
オプションを利用することが前提のため、オプションもハイフンを利用せずに利用できる。
プロセスはinitプロセスが最初に起動されるため、pstreeを確認すると必ずPID=1でinitプロセスが起動している。

プロセスの終了

killコマンド。3つのシグナル指定の仕方がある。 デフォルトは正常終了。
-KILLオプションは必ず大文字で。

パッケージ管理

パッケージ管理の出題数は多い。重要度がRedHat系で3、Debian系で3なのでパッケージ管理全体で6問出題される。
Debian系とRedHat系でコマンドが異なるので、どのパッケージ管理コマンドがどちらのパッケージ管理か覚えておくこと。

Redhat

yumコマンドはupdate, searchなどのサブコマンドをしっかりと覚えておくこと。

rpmコマンドのアップデートでは、-Fvhのほうが運用上ベター。インストールされていないものを新規でインストールするのは不具合が発生する可能性があるため。

Debian

同じサブコマンドでも異なる意味が利用されるので、気をつけること。

dpkgコマンドはアンインストールの方法が2種類ある。
-rは設定ファイルを残して削除、-Pは設定ファイルを含めて全て削除する。
ややこしいので試験に出やすい!


LPI-Japanホームページから無料でDLできる教科書

アンケート回答とメールアドレスの登録でどれも無料で読める。
これは読み応えありそうだし、けっこうアツい!
Linux標準教科書
Linuxサーバー構築標準教科書
高信頼システム構築標準教科書
Linuxセキュリティ標準教科書

第8回Jenkins勉強会参加メモ

日時:2013/12/20(金) 19:00-21:00
場所:ヤフー株式会社 11Fセミナールーム


発表内容

通常発表

川口さん:「2013年をJenkinsの歩み」
http://www.slideshare.net/kohsuke/ss-29339493

ヤフー石川さん:「Jenkins始めました。Yahoo! JapanのCI/CD」

株式会社シフト玉川さん:Jenkinsエンタープライズについて
http://www.slideshare.net/hirokotamagawa/20131220-8jenkins-jenkins-enterprise

LT

@akiko_pusuさん:おひとりさま~の1年後。発表者のその後を語る
http://www.slideshare.net/akiko_pusu/20131220-jenkinsakiko-pusu

@superbrothersさん:Jenkins With Docker
http://techblog.yahoo.co.jp/event/jenkins-with-docker/


川口さん:「2013年をJenkinsの歩み」

最初は1人で始めたJenkinsも 今年でJenkinsリポジトリ1090人がコミットした。1人平均20コミット。64commit/Day

Google/Microsoftでもplugin開発を行っている。

約18万のスレーブがJenkinsの計算ノードとなっている。


jenkinsの今年の大きな変化

デプロイがWinstoneからjetty://に変更になった。

コアではCredentialsプラグインを開発した。(鍵情報の一元化)

今までは各Pluginが個別に認証情報を持っていたが、一括管理できるようになった。

GitPluginの2.0メジャーリリース。

Git設定画面の簡略可。通常使わない機能は拡張オプションに格下げした。

Cloudbees。ジョブの階層構造化。リペレット(文芸的)ビルドの実施。

リペレットビルド
新規のジョブを作るとき README.mdにbuildというセクションを書いておくとJenkinsが認識できる。

README.mdが記載されているGithubのリポジトリのURLを使って、文芸的ビルドで新規ジョブを使うと、構成管理の指定とURLだけで勝手にビルドができる。 また、ブランチを作成すると、ブランチも自動的にビルドにしてくれる。


大規模ビルドに対応

今まではスレーブが多くなると、200スレーブで800スレッド必要だった。 今はsshやエグゼキューターの調整で、200スレッドにまでさげた。 マスターのjarキャッシュ方法も変更した。

マスター/スレーブの通信改善。
メモリ処理の変更。大規模テストレポート。HTTPセッションや遅延ロードの改良。


安定性

Jenkinsの結合テスト 複数OS環境でのJenkinsの起動の対応 Dockerによる外部サービスとの連携テスト


アジャイルアカデミーのワークショップにも協力
http://event.shoeisha.jp/aa/20140305/


JoCC
多くのJnekinsをコントロール。マスターのマスター。
社内のJenkinsを管理し、スレーブの管理など。


MacOSXのハック。仮想化をCloudbeesで開発。
MacOSXを起動。ZFSの利用。
ワークスペースのクローンをして複数スレーブで平行実行。
ワークスペース内に変更があると、差分だけ保存する。
http://pages.cloudbees.com/iOS_OSX_SignUp.html


ヤフー石川さん:「Jenkins始めました。Yahoo! JapanのCI/CD」

マーケティングソリューション事業部のインフラ業務担当。広告などのサービスを担う。

Yahoo!を見るときに右側に出てきたりする広告。

広告には2種類ある。

ディスプレイアウトネットワーク型の広告が今回のテーマ。 年齢や地域情報による最適化。

広告は膨大なリクエストをさばく必要があり、多くのサーバと開発者が必要。


Ops2名+Jenkinsで運用

プロも配信は9割以上を自動運用

社内GithubエンタープライズをJenkinsがフックすることで構成管理に登録、各種

マスター:3台 slave:マスターマイに約110台 ジョブ数 約300 プラグインはgit/github, coverity, rudeckなど


道のり

数名の有志によるボトムアップ活動

組織化→エバンジェリスト集団


独自のビルドスクリプトによる、統一したビルドライン

基本的には継続的デリバリーに書いてあるパイプライン構成に準拠。

ワンクリックでデプロイ可能。

管理職の理解や強力なサポートもあってCI+CDが達成できた。

手動時:2日→自動化により数時間にまで短縮


トラブル事例と課題について。

・連携にSCMポーリングを使っていたため、Githubエンタープライズに負荷集中 →ポーリングマストダイで解決!

・予算のある部署はSlave調達すぐできるけど、弱小部署はお金が。。。 →仮想感想の有効化!Jcloudsプラグインで解決! OpenStackベースの社内PaaSとの連携で物理サーバ不要。

ビルド終了で仮想サーバも自動削除 →クラウド側のリソースも節約。


その他の課題

  1. 細かいフロー(リリース、ジョブ数増加)
  2. テストコード(テストコード不足)
  3. もっと高度なデプロイに挑戦
  4. 全社的にはまだまだ普及できていない
  5. 他の部への伝承や教育

まとめ

CI+CDに大切な2つのこと

エバンジェリストたち

ボトムアップは大変。重要性を周囲に伝え、回りを巻き込んでいくひとが必要。 従来のプロセスや考え方を変える必要がある。

ルールや議論はほどほどで、まずはやってみること

JFDI精神! 縛り付けてやる気を削いでもしょうがない。

Yahoo!の私たちの部署は人募集してるから、CIとかしたい人は入ってね!


 質疑応答

Web Hookよりポーリングがいい場合って? PushしまくるとWeb Hookがムダに多くなるので。。。(クアイエットうんちゃらプラグインで抑えられる)

3,4年前からボトムアップを始めている。

テストが不十分なところとは? 一番はテストを書く文化がないところや画面周りのテストが不十分。Seleniumなどは推進している。


株式会社シフト玉川さん:Jenkinsエンタープライズ by cloudbees

第三者認証を行う会社。
マニュアル実行でテストを行っている。
会社以外のコミュニティではJenkinsユーザー会とSTAR

Jenkins有償版JEBCとは?
http://www.cloudbees.com/jenkins/enterprise

  • サポートあり。
  • 有償版独自プラグインが使える
  • 川口さんを含むプロ集団がサポートしてくれる。

JEBSの特徴:テクニカルサポート

OSS版の約8割のコードに貢献したメンバーのサポート (当然OSS版やコアの部分もサポートしてくれる)


豊富なプラグイン

  • 稼働率向上
  • 大規模開発向けのプラグイン
  • セキュリティ向上機能
  • リソース最適化

稼働率向上

  • マスターが落ちたときにスタンバイ機が自動的に起動
    • Jenkins Operation Center
  • ジョブをフォルダに入れて階層管理。
    • フォルダごとコピーしてフォルダごとに環境変数を変えて類似ジョブ量産。
  • テンプレートプラグイン
    • テンプレートで作成したジョブを記憶しているため、テンプレを変更すると全てに対応する。

Folderプラグイン

  • ジョブを作る際にフォルダーが選択できる。
  • フォルダーができるので、どんどんフォルダー内に追加していく。
    • フォルダーに設定した環境変数はフォルダ内のジョブ全てに適応される。
  • ビルドフローもフォルダと同時にコピーできるので、ビルドパイプラインを簡単に他のチームに展開できる。

テンプレートプラグイン

ビルダーテンプレート

ジョブの中のビルド手順をテンプレート化できる。
ジョブの種類から選べる。
Attributeでパラメータを追加できる。name属性とか、ID属性とか
既存ジョブにも適用できる。
「ビルド手順の追加」で「テンプレート」を適用できる。

ジョブテンプレート

ジョブ全体のテンプレート。
まずどのジョブを元に作成するか選ぶ
ジョブの設定をXMLで作れる。変数にしたい部分を設定してテンプレ化。
新規作成ジョブを作成しようとすると、ジョブの種類の中にテンプレが出てくる。
設定画面がXMLで設定した変数のみのシンプルなジョブが作成される。


セキュリティ向上系の機能

  • Role-Base Access Contorol Plugin
    • 権限の割り当てをもっと柔軟に。チームへの権限委譲
  • セキュアコピープラグイン
    • 複数のJenkins間で成果物を安全にやり取り
    • ユーザーが自由にDLできない
  • カスタムアップデートセンター
    • アップデートセンターを自社で持つことができる。
    • プラグインのインストール管理やバージョン制限など、プラグインの統制をすることができる。

  • Even Scheduler Plugin
    • スレーブの割り当てアルゴリズムの変更
    • 「このジョブをやったことあるスレーブ」から「今空いているスレーブ」へ
  • VMware vCenter Auto-Scaling Plugin
    • VMware vCenterのマシンプールから自動的にスレーブを生成、割り当て
    • ビルド前後の初期化やスナップショットのリストアなども可能
  • Skip Next Build Plugin
    • 指定した時間はビルドを禁止できるプラグイン

Jenkins Boot Camp 翔泳社の「Agile アカデミー」の一環で開講。 次回は3/5(水) 1日かけて「ジョブ書いたことない人」でもビルドパイプラインくらいまでできるようになる。



@akiko_pusuさん:おひとりさま~の1年後。発表者のその後を語る

発表して変わらないこと、変わったこと

Jenkinsの立ち位置が変わった。 パートナー会社によりジョブ管理ツールが到来。Jenkins不要説。。。?

「自動化して嬉しがる」時期は終わった
「自動化を意識する」時期に入った。
Jenkinsに期待すること!自動化のスタートアップを支援すること
手順の妥当性を繰り返し検証・ジョブが確立すればどこで実行してもかまわない。
それ以上改善や修正がないジョブはいらない。リソースのムダ。

執事の方向性

サーバのセットアップ・テストにフォーカス
内製システム/業務アプリのテストにフォーカス。
定常情報システム業務の自動化。


まとめ

Jenkinsの立ち位置が変わった。スタートアップを加速する。

自動化できないことにこそ、みんなの時間を割きましょう。


@superbrothersさん:Jenkins With Docker

Yahoo!入社5年目

Dockerとは

LXCベースの軽量仮想化
コピーオンライトのファイルシステム

仮想マシンと比べて軽量!


Jenkinsでジョブごとにクリーンな実行環境を一瞬で作ることができる。

ジョブの中でdocker runを実行・コンテナ作成後テスト実行。その後コンテナ廃棄。

Dockerを使うことでクリーンな環境が一瞬で手に入る。

JenkinsとDockerを組み合わせると工夫しだいでおもしろいかも!!



所感

とりあえずうちの会社で誰か早くエバンジェリストになってー!

徹夜状態→Java研修→勉強会で起きていられるか不安だったけど、杞憂に終わりました。
濃い内容ばかりで寝てる暇なし!

XP入れ替えに乗じてGETしたPCにマスター一台モグリで動かしているだけの自分からしたら輝かしい世界でした。
懇親会にも参加させていただいたけど、技術的な話よりまずは既存プロセスにかかわっている人たちのアレルギーをどう下げるかという話がメイン

サーバ連携テストとかやっているので、DockerとかChef絡めたビルドはぜひ挑戦してみたい。
まぁまずはLinux上のJenkinsでビルド通せるようにしないといけないんだけど。X11連携、X11連携

著者の方とお話できたのもなかなかの収穫。