または Kanazawa.rb meetup #45 で無双してきたよ！の話。
今回はタイトルを「はじめてのC☆I」にした。要するにテーマは Continuous Integration である。
最初の段階ではそんなに深い意味は考えてなくて、単に meetup #45 はもくもくじゃない回をやるタイミングだったのでどうしようかなと考えた時に、手持ちのネタとして比較的ライトに開催でき、かつハンズオンで時間稼ぎできるんじゃないかという気持ちで考えていた。（実は）
今回はそんな meetup #45 にいたる準備と開催中に感じていたことをつらつらと書いてみる。
CIを体験するだけに集中できる内容に
ハンズオンについてはとにかく「テーマ以外のことを気にしなくて済むように」に集中して考えた。これは以前 Heroku ハンズオンをやって、Windows で Rails の環境を用意するのが大変、Windows で Git + SSH の環境を作るのが大変、PostgreSQL の環境を用意してなかった、など「HerokuというよりはRailsに手こずった」印象が残っていたためである。
ということで
- GitHub アカウントだけ事前に用意してもらう
- こちらで用意したリポジトリを各自が fork
- GitHub アカウントで CircleCI にログインしてリポジトリと紐付ける作業
- CircleCI 側で自動でテストが走るように元のリポジトリで細工しておく
- リポジトリの中身はだいたいみんなが分かるだろう HTML, JS, CSS だけのもの
という設計にした。
※ 当初 45 分程度を予想していたのだが、余裕を見て 1時間に設定したところ見事に 45 分で終わってしまい、最後に急遽自動テストの環境をその場で用意することになるとはまったく予想していなかったが…。
これで「言語の環境がどうとか」「テストコードがどうとか」「テストの書き方がどうとか」全部すっ飛ばせるでしょ、という読み。
用意したのは以下のリポジトリ。
wtnabe/todomvc-vanillajs: forked TodoMVC (VanillaJS version)
内容はなんでもよかったんだけど、あとで中身に興味を持っても意味のあるものにしておきたかったので、いっとき流行った TodoMVC の中の VanillaJS バージョンを用意した。
（実は最初に自分を盛り上げるためにやったのはこのリポジトリを本家の TodoMVC のリポジトリから分離する処理を自動化することだった笑）
あっ、そもそもCIってなんだっけ
しかし、じゃあいざ人前で CI で喋るとぞとなった時に、自分の中にちゃんとした CI 像がないことが分かってきた。なんとなく自動で何かが処理されて、結果の通知が Slack で受け取れて…いやいや待て待て、通知の話は CI の必須要件じゃないよな。そもそも CI を入れて本当に嬉しいことって何？みたいな疑問が次から次へと出てきて、タイムテーブルは埋まるけどほんとにこんなんでいいのか？と不安になってあれこれ調べていた。
そんな時見つけたのが ThoughtWorks の CI に関するページだった。
Continuous Integration | ThoughtWorks
とてもよい内容だったのでこれを使ってイントロを喋った。曰く
チェックインごとに自動化されたビルドによって検証され、チームは問題を早く検出することができるようになる。
これですよ、と。問題は早く発見できた方がその解決も早くなる。とてもシンプルだけど大きなメリットだと自分は感じたので何はともあれ最初にこれを話した。
あとは戦場のリアルな話も、GitHub Flow や Continuous Deployment の話も役者が揃っている。ぼくは安心してピエロになってみんなが手を動かしやすい準備と雰囲気を作るだけ。
GitHub Flowの話からworkflow話が盛り上がった
当日いちばん盛り上がったのは、CI ハンズオンでも CI 話でもなく、実は workflow の話だった。（もちろん CircleCI ハンズオンもそれなりにウケたんですよ！）
GitHub Flow は pull-req を中心において branching をシンプルに、ガンガンリリースしていこうという workflow だ。
- Understanding the GitHub Flow · GitHub Guides
- GitHub Flow (Japanese translation)
- GitHub FlowとCIでモダンWeb開発 // Speaker Deck
これを紹介し、pull-req の画面上で CI の様子が確認でき、master へ merge することで CI サービスから deploy できることを示してからが、がぜん盛り上がった。
- そうは言ってもいきなりリリースは怖い
- staging を用意して自動でそっちにリリースすることもできますよ
- いやいや、やっぱ develop ブランチはあった方がよいのでは
- 開発期間やチームの大きさにもよるかもしれないですね
- 話ずれますけど、レビューのキューが詰まってコンフリクトが頻発しています
- branch の寿命が長すぎる、変更の影響範囲が広すぎる、チーム内のレベル差が大きすぎるなどあるかもしれませんね
- そこだけ別 branch を用意した方がいいかもね
自分が GitHub Flow を採用しようと思った理由
当日は整理できていなかったのでうまく話せなかったが、あとで思い出したので改めて書き起こしてみる。
自分が（ほとんどのコードで）GitHub Flow を採用しているのは何より
制約が単純でツールがよくできているから
である。
それ以前は
に紹介されている、いわゆる Git Flow と呼ばれるものを採用していた。まずは develop ブランチを用意しましょう、ってやつ。
Subversion 時代の感覚（branch の寿命が長い開発）にはマッチしていて個人的には割とよいなと思っていたんだけど、バージョン管理初心者にはいきなり local だ remote だ用語がバンバン増えていく中で branch の意味とか細かく覚えてられないのが正直なところだったらしく、すぐにはリリースできない、あるいは明日リリース予定のものが remote の develop に突っ込まれて hotfix がリリースできなくなるなど、変な混乱が収まるまでしばらく時間を要してしまった。すぐにリリースしない branch が他の branch を block してしまう、ということが直感的に理解できないようだった。
結局、master と develop が一致していないといろいろ面倒になってしまうのであれば、そもそも develop は要らないのでは？と思っていたところ、GitHub Flow を知り、これがぴったりマッチしたのでそれに飛びついた、というのが実情である。決して GitHub Flow はレビューしやすい、とかそこまで積極的によりよいプラクティスを求めていたわけでもない。とにかくシンプルなので変なことが起きにくいのが最大の利点だ。
（これはバグがリリースされにくいという意味ではなく、メンバーの理解度が高くなくても変なことが起きにくいという意味。残念ながら。バグは最悪 rollback すればなんとかなるので。重大さにもよるけど。）
改めてCIとworkflowについて思ったこと
自分の場合は CI と CD ( Continuous Deployment ) は少なくともうちの（比較的小規模な）Web 開発においてはリリース担当者などの blocker 要素を減らしつつある程度の品質を確保するために不可欠な要素になっている。
以前は全員が capistrano を叩けるように教育もしたけど、今はそれも不要になった。こうして極力軽量なプロセスにしないと回らない現実と戦うのが至上命題だからこそ CI と GitHub Flow がマッチしているのだけれど、ここにこだわってやってる現場は（少なくとも近辺には）あまりないかもしれない。参加者の中ではやはりもっと branch の寿命も長いとか、そもそもコードをクラウドに乗せられないので SaaS な CI に頼るのは難しいという人が比較的多かったように思う。
そういう現場はもちろんそれなりに多いだろうし、そこで GitHub Flow を入れないなんてクソですよという気は毛頭ない。ただちょっとこの地域の Web 界隈の、特にフロントエンド方面の人を煽るつもりはあったけどね。
CI と GitHub Flow でリリースサイクルを小さく速く回すためには、当然だけどフロントエンドの人も Git を使ってコミットし、レビューする人が GitHub 上で pull-req を merge するのが最も合理的だ。特に若い人にはそれくらい当たり前にこなせるようになってもらいたいという願いは込めていた。
ヘビーウェイトなプロセスはそれに見合う重さを持つプロダクトに適用してしかるべきであって、ライトに回せるはずの開発をヘビーに回す必然性はないと自分は考えている。それは単なる不勉強だろう。そういう気持ちは込めてある。採用するかしないかは現場次第だし、現場現場でプロセス、ワークフローはカスタマイズが必要だとは思うが、伝統的な人力ベースの重たいワークフローは昨今の多くの現場で割りに合わないのではないか、というのが自分の意見だ。まして制作よりの小さな Web 開発であればなおさらである。
あなたの現場には変な待ちとか無意味なブリッジとか妙に属人化したタスクとか謎の○○職人とか、ありませんか？ それって本当に必然性あるの？
コードをクラウドに乗せられない問題と本当のコストと最初の一歩
最後はややポエミーに。
当日の timeline でよく流れていたのはソースコードを GitHub に置けないというものだった。（紹介した SaaS が GitHub にしか対応していないとか、結構多かったからだろう。）GitHub は CI の必須要件じゃないので、紹介したツールにこだわらずに目的を達成することができれば別に GitHub にコードを置く必要はないと思う。とは言え、時間短縮をするためにはよくできたツールに乗っかった方がいいよ、というのは長いこと自分の価値観の中心にあるものだ。
例えば実際に CI を導入しようと思ったら誰がその準備をすることになるだろう。だいたいはエース級の「様々な仕組みをよく理解して適切なコミットを作れる人」がやると思う。その時、エースがどれだけ時間を使えますか？ いやいや、そんなところに時間使うなんて無理だし他のやつじゃ CI なんて分かってないし無理だよ、ってことになっちゃわない？ それって要は最初から無理って決まってるってことだよね。
最近、変えるための準備に時間が必要なのではなく、変えることに時間が掛かるから変えられないのではないか？ということを時々考えている。そのルールは本当に合っているの？ ルールが目的化していない？ 大事なことはなんなの？ 流行りのツールを取り入れることは目的じゃないけど、だからといってこれまでのルールが本当に理に適っているとは限らないよね。現時点では仕方ない、って判断は普通によくある。過去においてもこの「現時点」はいくつもあったはずだ。だったら見直さなきゃ。
すぐにいっぺんに全部変えるのはそりゃ無理だと思う。でもこの問題に取り組もうとしている人は、問題を適切に分解して解いていくことを、それをソフトウェアで実現する人たちなんだよね？ ちょっとでいい、すぐにできることでいい、変えられることから変えていけばいいじゃん。
さーて、次は何をかましてやっかね。
Subversion と Git の場合、git-svn という便利なツールがあるらしい。使ってないからよく知らないけど絶賛する声をよく聞く1。
でも CVS の場合はそこまでいいものはない。一応 CVS リポジトリの import 自体は working copy 上で
git cvsimport -C DEST
って打つと DEST 上に .git/ を作って import してくれる。ただし cvsps という別なツールに依存しており、かつ普段の git のスピードからは想像がつかないくらいの時間が掛かる。
それでも git log が使えるというメリットは結構大きい。日常的に git にも CVS にも commit しますという目的に使うのは厳しいみたいだけど、コードを読むという目的には十分使える。
cf.
自分の場合は git と生の svn を別々に使うので特に不満はない。 ↩
以前Net::SSH で明示的に password 認証にでまったく同じ現象に悩んでいたんだけど、またハマったのでもう一度書く。
ポイントは
自分の ssh_config と秘密鍵を認証に使いたくない
で、これの実現のためには
set :ssh_options, {
:config => false,
:keys => []
}
と設定されていればよい。（:keys => nil はダメ）
set :ssh_options[:auth_methods], 'password'
だけでうまくいくんじゃないかと思ったけど、これはなんでかうまくいかなかった。ちゃんと内部で password 認証だけに絞られてるように見えるんだけど、そういうわけではないのかな。
Capistrano 2.5.5 で確認。
それか capistrano で使う秘密鍵の名前はデフォルトとは別な名前にしておくという方針がいいのかもしれない。
戯れに Q - [kju:] で Mac 上に Linux 環境でも作ってみっかーと思ったけど動かなかった。x86 環境は Pentium II 18MHz とかいう理解できない数字で動いてたけど、修行する気はないので却下。
別に Mac on Mac はできなくてもいいけど PPC 仮想マシンが使えるようになったらそれなりに嬉しいかなーと思わなくもない。どう使うのかはボンヤリしてるけど。（たぶん Linux でしかできない作業、ext3 で mkfs とかをやろうとしているのだろう。でも仮想環境でそんなことできるんかいな。）
今日の「お前そんなことも知らなかったのか」
Debian etch に上げた機械で喜び勇んで emacs-snapshot を入れようとしたらそんなものは search に引っかかってこない。うーん。うーん。どうしよう。とりあえず emacs だけ入れられればそれでいいんだけど、そもそもそういう場合の apt line の書き方すら知らない。（ヒドイ。）
AptGet - Debian GNU/Linux スレッドテンプレ
で 99target を /etc/apt.conf.d/ に置いたら testing, unstable を明示することでそこからインストールできることを知るが、なんか全体的に testing も unstable も選択肢に入ってきちゃうのがちょっと不満。というか emacs-snapshot はまだ unstable に居るのにちょっと驚いた。
そこで backports なんてものがあったのをハタと思い出し、きっと backports で etch に持って来れるだろう、と思ったらこれが Bingo.
を sources.list に追加し、apt-get update …
失敗します。公開鍵をインストールしないといけないのでした。
指定された鍵のファイルを取得して、root 権限で
apt-key add FILE
したら使えるようになった。なるほどねぇ。
なんかまだ cron で動いているものと動いていないものがいたり、bind が立ち上がらなかったりしてあちこちおかしい。bind はバックアップ用に動かしているやつなので深刻じゃないんだけど、ここで確実に問題に対処するノウハウをモノにしておかないと本チャンの bind の載ってる Debian を上げるときに困るのよね。原因は当たりついてるんだけど、対処の手順がよく分からねっす。
[追記] 全部問題なく動くようになった。
bind の問題は以前 FreeBSD で経験済みで、
- rndc での認証が加わったのでその設定が正しくないと動かない
- 正しく設定しても daemon の起動のタイミングの問題で動かない場合があるので、考えるの面倒でかつ許されるならシステムごと再起動すると直ったりする
- hostname のチェックが厳密になり、以前は大丈夫だった名前でも 4.0(etch) で動いているバージョンでは弾かれたりする。要対処。
cron は cron.d/ 以下のファイルがどうもインストールされていなかったらしく、ファイルを修正したらインストールされて動くようになった。なんだか不思議。どうもこの辺の cron.d/ 方式の動きがよく分からないんだよな。
いや、いろんな情報やネタや資料を提供してくれるという意味では多くのサイトに対して感謝しているし感謝しなければいけないのだろうとは思うのだけれど、自分は結城さんのようにデキてないから感謝を自覚することなんてめったにないのだ。
しかし、「おれか？おれが書いているのか？」と思うほど1痛快なエントリが連発される「雑種路線でいこう」には本当に本当に感謝したい。
ほっとくとすべてのエントリを del.icio.us に放り込みそうになるので思い切って今後は何もしないと決意をする代わりに、ここにエントリを起こそう。
ありがとうございます。これからも多くの刺激を勝手に受けていきます。できればしばらくは書き続けてくださいな。
実際には自分より圧倒的に優秀で圧倒的に経験豊富な人が書いているわけだけどX-P ↩
FreePWING による各種辞書 にある英辞郎データの変換スクリプトがうまく使えない。具体的には ' で止まる。
パーサ見なきゃいかんのかなぁ。まぁわざわざ英辞郎を EPWING にする人なんてあんまりいないんだろうけどねぇ。
ファミリーログオンを優先しておくと Windows にログオンするときユーザー選択のダイアログが出る。
こんなノウハウ、もう覚えちゃいねーよ。
Zebedee は慣れると便利だけど、最初けっこう戸惑う。
| ssh | Zebedee | |
| バイナリ | client, server でベツモノ | client も server も同じ |
| サービス動作 | サーバだけ | client も server も可能（detached true するだけ） |
| 認証 | サーバだけ（当たり前） | client も server も可能。でもデフォルトでは認証しない。 |
| tunnel を利用できるホスト | デフォルトで localhost のみ | デフォルトで他のホストも可能 |
| default listen port | 22 | 11965 |
| forward する port の制限 | できない | できる |
- Zebedee はデフォルトでは認証しないでそのまま繋がっちゃう
- 認証したければ鍵を作る
- Zebedee の client, server という言葉は tunnel の方向しか意味しない
- Zebedee は最初から tunnel 目的のプログラムなので、デフォルトでは client へ接続できるマシンはすべて tunnel を利用できる（ssh はデフォルトでこれを禁止している）
- 認証の書き方がちょっと戸惑う。公開鍵を置く側で checkidfile キーワードを利用する。秘密鍵は設定ファイルにそのまま書かれる形になる。（include キーワードを使っても秘密鍵をそのまま書いても同じ）
XnView 発見
- ものすごくたくさんの形式に対応している（ほんとにものすごい）
- ファイル内に含まれる画像もそのまま見れる（PowerPoint に貼り付けてある画像を直接開ける。でも同じことは Excel や Word に対してはできない。）
- PDF も見れる（さすがに画像向きなのでフォントとかあれだけど）
- たくさんのプラットフォームで動く
- たくさんの言語をサポート（デフォルトで日本語対応）
- ファイラー
- フィルタ、補正処理
- デスクトップ画面のキャプチャ
- TWAIN で読み込み（Windows のみ）
- 画像の検索（ファイル名とかサイズとか）
- 画像の連結
- TIFF の複数画像格納
など恐ろしく芸達者。デフォルトは画像ファイラーだけど、関連付けてビュワーとして使うこともできる。
個人的に嬉しかったフォーマット
- ai
- e?ps
ai では日本語の表示はできなかったが、eps ではできた。pdf では日本語も読めるが、フォントの展開をしてくれないようで、荒いビットマップの文字が表示された。
他にも PaintShopPro や PhotoDeluxe、特定ハードの独自フォーマットなんかにも対応しているし G3 を始め各種 FAX のデータもイケるので、持っててよかったと思う機会は出てきそうだ。
メモ
- ツールバーのアイコンをスキンとして入れ替えることができる
すげぇ。デフォルトのアイコンはあんまりいい感じじゃないけど、標準で入っているものの中に十分かっこいいのがある。
- サムネイルは一工夫
サムネイルはデフォルトでは ViX に比べて見やすくない。これはデフォルトではオンメモリでしか処理しない方式なので仕方ないかと。設定すれば ViX や Explorer みたいにサムネイルをキャッシュすることも可能。キャッシュを作成するように設定するとメモリ消費は ViX とあまり違わない。（デフォルトはやはり食う。）
ただし、キャッシュするようにしてもサムネイルの画質が上がるわけではない。画質を上げるには [ツール] → [オプションズ] → [ブラウザ] で High quality for thumbnail にチェック。
残念なのは
- swf 非対応
- svg 非対応
- 完全フリーではない
って点ですな。
商用の場合でも Linux, FreeBSD バージョンはフリーってのも面白い(^^;
ってのがあった。ってことをメモ。