勉強会のレポート(メモ)です。
参加したのはこちら、「Jenkinsおじさんと仲良くなる方法」
会場はサポーターズさんです。
今日話すこと
CIツールを初めて使う方に。
「こんな感じで使ったらうまくいったよ」、「うまくいかなかったよ」という話をします。
具体的な使い方よりも心構えについて話します。
CIエンジニアになるとこうなる
・見た目とかどうでもよくなる
・どう手を抜くか考える
・手動で何かをするのは悪いこと、ワンボタンでできないことは悪いこと(難しい手順で何かをやるのは悪い)
・ドキュメントを読むのがうまくなる
・謎のAPIとかツールを触っていけるようになる
・フルスタックエンジニア(なんでもできる人)っぽくなる
Jenkinsおじさんと仲良くなる方法
最初に結論から
仲良くなる方法はないです！
なんでないのか
・そもそも、Jenkinsはいろんな環境に依存してくる
お客様というよりも社内に影響してくる(新しいことを始める、社内の環境が変わるなど)
・Jenkinsはツールを使うツールなのでツールが壊れるとどうしようもなくなる。
ちょっとでも仲良くなっていく方法
まず精神論から、なかよくなるイメージ
Jenkinsおじさんはツンデレです
・ちょっと何かあるとすぐ止まる
・もしあなたがCIエンジニアの場合、Jenkinsが止まると回りからすぐに言われます
・何もしなくても使用者や環境のせいで止まります
・Jenkinsおじさんはまだ8歳なので大目に見ましょう
Jenkinsおじさんは病弱です。
いろんな理由でとまります。
CIは手段です、目的ではありません
また、3Dなもの・リアルタイムなものは苦手です。
ゲームでいうとレベルエディタのようなものをCIでやるのは無謀です。
できることできないことを把握しましょう。
必要ならば別の手段も考えましょう。
Jenkinsおじさんと付き合うためにどうすればいいのか
どういうアプローチが必要か、
ツールの使い方ではなく、何に使うのかという話
1.ジョブの名前と場所は大事
よくわかる名前をつけましょう。
プログラムのメソッド名よりも考えてつけましょう。
なぜなら使う人が自分だけではないからです。
簡単なドキュメントを作りましょう
これはドキュメントを作れというわけではなく、
簡単なドキュメントで十分な説明のできるジョブにしましょうという意味です。
あなたがCIエンジニアの場合、そうしないと毎回聞かれることになります。
非エンジニアが触るジョブの説明は超丁寧にしましょう
Jenkinsの取り扱い説明書のように書いてあげるのも手。
ジョブのリストはabc順なのでまとめたいものは手前に置くといいでしょう。
2.ジョブ自体をシンプルにしましょう
「ジョブの中身がシンプルか複雑か」ではなく、
「使ってる側から見てシンプルか複雑か」です。
ジョブにパラメータをあたえることができるが、それよりもジョブをコピーして少し変えたほうがいい。
大量のパラメータがあった時に、それを全て正しく設定できる人間はいない。
パラメータがいっぱいだと、問題が起こった時にどういう状況でおこったのか把握できなくなる。
ジョブ同士の依存関係を減らしましょう
ジョブ同士の前後関係が複雑など何をやっているのかわからなくなってしまう。
何か問題が起こった時、どういうルートで起こったのかたどるのが難しくなる。
基本的にpipelineを使えば簡単に実現できると思います。
ヒューマンエラーをおこさないように、調べる人にとってわかりやすくしよう
3.情報はすごく大事
ログはめちゃくちゃだそう。Jenkinsは壊れるのでログは役にたちます。
ログファイルは成果物として保存することもできます。
時間も大事
タイプスタンプ機能をどのジョブにも入れましょう。時間がかかるものだと特に重要。
pipelineならstageという機能を使えばstage内でかかった時間もわかるので便利です。
あまりに時間がかかるようならタイムアウトやリトライするようにしたほうがいいかも。
Jenkinsのログも読めると便利
Javaで動いているのでJavaのログがでてきます。
ちょろっとだけ読めるようになると便利です。
生のデータはJenkinsのホームディレクトリの中にあります。
調査などに時間をかけたくなければログをだしましょう。
4.新しいものは正義
Pipelineを活用しましょう。最近は結構安定しています。
ループやイフを使いたい場合や最終確認ボタンみたいなのを出すことができます。
ただできないこともまだあります(Unityを起動するなど)
そういう場合はそこだけジョブに切り出すとかもあります。
サーバー側は全部パイプラインでいいと思います。
Jenkinsのバージョンも最新がいいかも
最近はおもむろにバージョンを上げても問題ないと思いますが、バックアップをとっておきましょう。
新しいほうが幸せ化かも・・・？
5.いつでもJenkinsを復元できるようにしてください
最悪、作り直さなければならないときが来ます。来ます！
いつ壊れてもすぐ復旧できるようにしましょう。
たとえばAWS上にあるのならそれをバックアップをとっておくとか。
成果物はいらない、設定だけでOK。
これはすごくすごく大事です。
まとめ
・CIツールは壊れるんだよねという心構えで接しましょう。
・CIは手段です。
・説明はプログラムを作るときよりもわかりやすく。
・使う側から見てジョブはシンプルにしておきましょう。
・ログや情報はとても大事。
・バックアップを絶対に取りましょう。
質問
Q.Jenkinsはよく壊れるといいましたが、Jenkinsのサーバーが壊れるのか、ジョブ単位で動かなくなるのか
A.どっちもあります、Jenkinsにくっついてるスレーブが問題の時もありますし、人為的な要因でジョブが壊れることもある、どうしようもない問題もあります。
何にせよあなたがCIエンジニアの場合、全ての状況において「Jenkinsが壊れた」という報告が飛んできます。
Q.Jenkinsをサービスに導入するタイミングは？
チームのスケールによります。2、3人ならいらないが、20人30人規模であるならなるべく早くやりましょう。
規模が大きければ大きいほどリターンも大きいです。
例えば全員が手動でビルドしてテストしているなら、ビルド時間は大きなロスとなってします。
