devsumiねデブサミ。今年も行って来ました。
17日午前中だけなんですけどね…色々と厳しい状況だったけどJenkinsだけはききたかったので!
「Continuous DeliveryとJenkins」
概要(記憶に残ったのだけ書いとく)
- マシンの性能は上がっている。一方人の性能は変わらない→それなら自動でできることはマシンにやらせるべき
- 高性能マシンを並列化しまくったら時間もかからないしコスト削減になる
- というか時間=コストってことだもんなぁ、人月計算してる以上はと思ったりした
- 人の性能は変わらんのでコード書く速度はそんなに早くもならない(むしろ大規模になると低下したりもする?)
- 削れる時間はビルド時間、テスト実行時間→そこでCIツール
- ただCIツールを入れるだけでなにもかも解決するわけではない
- たいていはバージョン管理をしているが、サブミット(コミットとかチェックインとかツールによっていい方は様々だが要するにファイルを共有サーバに入れることだ)する前にビルドが通ること、などというルールがあったりすると、結局ローカルでビルドして直して…となってなかなかサブミットできないし、CIツールの意味がないし、ローカルの環境よりサーバのほうがスペック言いに決まっとる
- 現状でうちでもビルドと単体テストと動的メモリテストなんかはJenkinsを使っているが、基本ローカルで単体テストに通ることを確認してから入れる決まりになっている。んで、うちはC++つかってるんだが、でかいやつになるとビルドに5,6分はかかる…ちょっと直してデバッグしてビルドして…で一日かかるとかザラ
- なので、ビルドはもう完全にCIツールに任せてしまいましょう、という話だった。
- あとこれとパイプライン方式を混ぜればなんかうまいこと運用を考えられそうだ
- とりあえず思ったのは、
- コードサブミット用ブランチをひとつ作る。開発者はここにビルド成功するかどうか分かんないけどとりあえずコードをサブミットする
- Jenkinsはサブミットされたらビルドを開始する。ビルド中開発者は別の所を修正したりテストを書いたりとかしておく
- ビルドが失敗したらメールが来る。開発者は直してサブミットしなおす
- ビルドが成功したらJenkinsがテスト用ブランチにサブミットする。サブミットがあるとテスト用ブランチで自動テストが走る。失敗したら(ry)。成功したら次のブランチもしくはマスターブランチにサブミット
- 問題になりそうなのは衝突が起こった場合だな。これはやっぱり手動でしないといけないかもしれない。
- あといま、自動メモリテストのジョブが成功したら自動的にリリースビルドのジョブが走るようにしてるので、*用ブランチというのをいくつも作らんとサブミット用ブランチ一つとマスター用ブランチでよいかもしれない
- Perforce連携のプラグインてないんですかね…
「仕事のバトン、渡っていますか? - プロジェクト管理におけるコミュニケーション基盤作り」
どうしようかなーと思ったんだけど一応行ってみた。ちょうど課題管理のことは問題になってるので。ちなみにうちはRedmineをつこうております。
記憶に残ったとこだけ
- 課題管理は特に理由がないのならExcel最強
- 曖昧なトリガはチケットとしては不適当。結局グレーのまま放置される
- はっきりとしたバグとかそういうのだとチケット駆動にはしやすい
- チケットの内容は丁寧に書きましょう
- チケットは共有しているものだという意識を持ちましょう
- 計画段階切っていくチケットはよっぽど慣れていない限りあんまり有効でない。計画の段階では大抵のことは曖昧なため(もしくは曖昧なこともわからない(まぁあるあるですな
- あとツールはいくつも使うな(あるあるすぎますな
- メール、電話の内容も全部課題管理表に書きこむこと(うちはこれをバージョン管理ツールでやってしまっている
いやあ本当にまっとうなことばかりだったのですみませんという感じでした。