開発プロセス

2013年12月06日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/06担当 (2回目の登場)

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場の悲鳴をお届けします。

2012/06末 こんにちは、『結合苦』さん

前エントリの継続RPMビルドする仕組み作りの裏では『結合苦』との戦いを繰り広げていた。

ファイル配置程度のインストール作業は、パッケージングによって軽減されていたが、コミッターは結合作業の事は気にせず、思い思いのタイミングで新機能をコミットして来る状況だった。当時の結合作業の大半は自分ひとりで行っていたので(そして今も)、システム結合に悩まされるのは自分ひとり。極度の結合苦に悩まされていた日々。

  • 「何故こうなったのか・・・」
  • 「何故こうなるのか・・・」
  • 「いっそのこと、開発を一時中断できないものか・・・」

苦い経験を踏まえ、後に実感した事は、

  • 「新たなRPMがビルドされてから結合するまでの時間が長ければ長い程、結合苦に陥る」

今となっては当たり前な着地点だが、当時は、それを身体で感じられなかった頃。結合苦を乗り越えたくて、早め早めに結合する作業へ挑み始めたのが、2012/06末。

2012/07 「インスタンス起動/破棄」連続成功への道

Wakame-VDCにおける結合成否の指標の1つ、それは、WebUIからインスタンス起動してインスタンスにログイン出来る事。もしもログイン出来なければ、容赦なく結合失敗と判断されてしまう。たかがログインの舞台裏には、幾つも前提条件が存在している。

  • インスタンスが起動している事
  • インスタンス管理エージェントが起動している事
  • APIサーバが起動してる事
  • WebUIが起動してる事
  • DBサーバが起動してる事
  • ○○・・・が起動している事

更に各コンポーネントが協調して動作する必要がある。

  • 起動順序通りに起動してる事
  • 各configが正しく設定されている事
  • 初期データが投入されている事
  • etc.

これ等は氷山の一角で、前提条件は他にも多々ある。何か1つでも条件が不足していると、ログイン可能状態にならないのは言うまでもない。動かない原因を1つ1つ分析し、動かすための組み合せを探って行く。とある組み合わせで動いていても、新たにビルドされて来た新機能入りRPMパッケージで入れ替えてみると、あっさり動かなくない。ふり出しへと戻される・・・。

2012/08 結合失敗回数と結合成功回数が、逆転する

原因を調査・分析、新たな動く組み合せを作っては、新たな変更によって壊れて行く。この泥臭い修復作業を、ただただ、繰り返す。何度か調査回数を重ねて行くと、似た調査パターン・コマンドセットに分類されて行く。例えばインスタンス作成失敗時エラーログに対するgrepコマンドの組み合わせ。そんな時はコマンドヒストリを駆使し、以前使ったコマンドを分析。少しずつ改良を重ね、手順を少しずつ確立させ、継続的に改善して行く。

  1. 調査手順を確立
  2. 調査手順を分析
  3. 手順を簡略化・単純化
  4. 内容によってはスクリプト化

結果、出来上がるのは、アプリケーション監視相当の仕組み。外堀が埋まって行った。

また、その当時、調査作業と並行してデプロイ作業改善も同時に進めていた。2012/07末にはパッケージ自動ビルドする仕組みを作り上げていたので、残り作業は、

  1. パッケージリポジトリを常時監視
  2. リポジトリが更新されていれば、新パッケージを関連ノードにインストール
  3. インストール後、プロセス再起動

この一連の流れを行うデプロイパイプラインの成長につれシステム全体が安定したのは、2012/08末の頃。 ただ、これは、特定環境におけるパイプラインであり、ポータブルなパイプラインを手に入れるまでには、まだ時間が必要だった。その辺の話は、別エントリに持ち越し。




編集
@hansode at 10:00|PermalinkComments(0)TrackBack(0)

2013年12月04日

このエントリーをはてなブックマークに追加

Wakame Users Group Advent Calendar 2013 12/04担当

Wakame2-logo-mini

「使ってみました/インストールしてみました」は他の方にお任せし、現場から見た風景をお届けします。

お粗末な対応からパッケージング生活へ

「Wakame-VDC RPM化」の話が舞い込んで来たのは2012年03月。RPM化以前のパッケージデプロイ手順は、下記の通りで、大分お粗末なものだった。

  1. ビルドサーバでbundle update等を半手動実行
  2. ビルドサーバからアプリケーションサーバへrsyncによる半手動デプロイ
  3. 依存関係に従い、プロセス再起動

少なくとも半年以上は同様のお粗末な対応でその場をやり過ごし続けていた。やがて、RHEL系の構築需要が高まり、政治的圧力も手伝い、RPM化が本格始動したのが2012年03月。ここからパッケージング生活へとシフトして行く。

RPM化へ向けて生きた参考材料収集

参考にしたのは、openstack-rhel。

当時は既にGitHubのおかげでrpmspecファイルを探す事も簡単になっていた頃。それまでは、SRPMをダウンロードしてインストールする等の作業を必要としたが、GitHub登場により状況は一変した。プログラミングのソースコードだけでなく、パッケージングの領域までオープンになりつつあった。

2012/04/17 rpmspec初コミット

最初の wakame-vdc.repoをコミットしたのは、2012/04/17。この日付には意味があり、Wakame-VDCがリリースされたのは、更に2年前の2010/04/17。2歳のお祝いと、成長の証として、この日にコミット。

2012/07/20 継続的RPMビルド開始 (cron方式)

初コミットからしばらくの間は手動実行で間に合う回数だったが、コミット頻度に比例してビルド需要が高まる。とある時期から手動運用では間に合わなくなり始め、リポジトリの先頭コミットハッシュを監視し続ける簡単な仕組みを導入し、自動ビルドさせる仕組みを導入したのが2012/07/20。小さな変化だったが、手持ち作業に注力出来るようになり、自動化による恩恵を、ジワジワと身体で感じ始めた頃。

2012/08/24 RPMビルド結果メール通知

継続的RPMビルドが安定稼働し始めると、『ビルド結果がどうだったのか』それを知りたい!と言う需要が高まり、ビルド成否をメール通知を開始。この頃から『少なくとも帰る前にコミットするルール』が開発メンバー内で自然に定着し始める。RPM化着手してから半年弱の出来事。

自動化体質へシフトし始めた半年間

パッケージングをきっかけに得た事は、数知れず。

  • 継続的ビルドがどう言うものか
  • 何を気を付けるべきか、何を気を付けるべきだったか
  • 開発プロセスの改善とは

自動化による恩恵を身体で感し始めた半年間。その後の品質向上について検討可能な時期へとシフトして行く話は、別エントリに持ち越し。




編集
@hansode at 10:00|PermalinkComments(0)TrackBack(0)