XP祭り「Pythonでアジャイル開発サイクル2010ver.」レポート

9月4日 XP祭り2010 ～アジャイル学園祭～(東京都)(#xpjug) で @shimizukawa さんの

「Pythonでアジャイル開発サイクル2010ver.」

というセッションに参加させて頂きました。
その場で、実行委員の@shibukawaさんが、「セッションに来られなかった人のために、レポーターをやる人」を募集していたので、それくらいならお手伝いできるかと思い、手を挙げさせて頂きました。
ということで、清水川さんのセッションのレポートを書かせて頂きます。

スライドについての補足的な話と個人的な感想等を添えながら纏めたいと思います。
セッションのスライドはこちらです。

清水川さんのセッションスライド

スライドは、id:amachangさんが作成したs6というHTMLプレゼンテーションツールを使って作られています。
使い方は、とりあえず←→↑↓ボタンを押せば大体分かると思います。(少し重いです)

セッションの概要

主に、アジャイル開発に必要になる以下のような自動化ツール類についてのお話です。

ソースコード管理の自動化
テストの自動化
環境構築の自動化
継続的インテグレーションの実施
ドキュメント生成の自動化

「これ全部 Python で揃うよ！」といった内容について、" Engineering Practice なコンテキスト" の話でした。

清水川さんの自己紹介

お仕事でも Python を使っており、昔は組み込み系の開発でXPを実践されていたそうです。
参加コミュニティは主に Zope/Plone, Sphinx, pyspa, XP 関連。
最近は、Deliverance/xdv といった、「Web フレームワークのテンプレを書き換えずにデザイン適用」する技術に注目しているそうです。参照

そして何より、最近翻訳本を出されています。

エキスパートPythonプログラミング

清水川さん(と実行委員渋川さん、他２名)による翻訳本です。
Python に限らずソフトウエア開発者全般にとって勉強になる内容なので、是非読むことをお勧めします。
セッションにもありましたが、 7〜11 章は Python と言うよりは XP (正確に言えば Python で、いかに XP のプラクティスを実践するか)について幅広く書かれています。

今日のセッションもこの辺のお話でした。

ソース管理の自働化

何を自動化するにしても、まずはコード管理から！

ソースの管理は、VCS (Version Controll System) を使用して行います。
これでソースそのものの管理、ソースの変更履歴の管理、そしてソースの共有を行うことで、以降の自動化の基盤を形成します。

VCS には CVS, SVN といった中央集権型(中央にセントラルリポジトリをもつ)と、hg, bzr, git 等の分散型(リポジトリのクローンが複数箇所にある)の大きく二種類があります。

清水川さんは、導入にサーバ等が必要ない"分散型"がおすすめとのことで、Python で作られた VCS である hg(mercurial) の紹介です。

導入と基本の使い方は以下、インストールは python のパッケージ管理システムである easy_install を使うとお手軽。

easy_install mercurial
hg init
hg clone

さらに、mercurial に内蔵されたサーバ機能を使えば、ソースのちょっとした履歴の確認や、共有のための公開が簡単にできます。

hg serve -p 8000

環境構築の自働化

プログラムはvscから入手するだけでは動かない場合が多い

関連するプログラム(依存ライブラリ等)を入手、配置
パスの設定、スクリプトの設置
環境設定ファイルを配置、必要に応じて変更

そこで、こういった環境構築を自動化するのが buildout です。

buildout は、buildout.cfg という ini 形式のファイルに環境構築に必要な情報を記述しておくことで、
構築を自動化します。(スライドには、Zope と Plone を自動インストール＋プラグインも入れる buildout.cfg の例)

設定を記述したら

$ hg clone http://xxxxx/ .
$ ls
bootstrap.py   buildout.cfg
$ python bootstrap.py
$ bin/buildout

これで環境構築完了。

これで完璧と行かない場合もあるけど、
だいたいの部分は上手く行く。

デモとして、zc.buildoutでGAEの環境を作成する例が実演されました。

cfgファイルは、テンプレートが多く公開されているので、少しいじれば使える物も多いそうです。

実行すると、必要なライブラリ等が展開されます。

appengine の場合はファイル数制限があるので、よく使うライブラリはあらかじめ zip に固めるみたいなことも、cfg の設定で簡単にできます。

仕組みとしては、"レシピ" という物を呼ぶだけなので、誰かが書いたレシピや、レシピを自分で書けば、いろいろな環境を構築出来ます。

テスト自動化

Pyhton には、標準で unittest ライブラリがありすぐでもテストが始められます。
それでは機能が足らない場合は、Nose や py.test、渋川さん作の PySpec(RSpec の python版)等が有ります。

テスト周りは、RubyやJavaの方がまだ少し強い面もあるが、pythonでも十分unittestは可能。

また、他の言語にはあまりないPyhtonの機能として、DocTestがあります。
これは関数にヒアドキュメントを書くと、テストとして実行できる機能です。
機能の説明が、そのままテストになるというスグレモノ。

こんな感じです。

def add(x, y):
    """ 二つの値を足します。

    >>> add(1, 2)
    3
    """
    return x + y

スライドには、DocTestを使ったTDDのデモFlashがあります。
これは以前、清水川さんが書いた以下のブログの転載です。

2006/05/21 PythonのDocTestでお手軽TDD - 清水川Web

注意点としては、docTest だけで何でもかんでもテストを書こうとしないこと。
しかし、関数の使い方の説明とテストがくっついているのは、ドキュメントを一元的に集約し、あっちこっち見に行かなくてよくなるという点で非常にメリットがあるとのこと。

告知

ここで、清水川さんが毎月やっている勉強会のお知らせ。

- Sphinx+翻訳ハッカソン (9/5)
- エキPy読書会02 (9/7)
- Python mini Hack-a-thon (9/25)

9月はほぼ埋まってしまいました>< 10月もやりますよ！

ということなので、興味の有る方は是非参加されると良いと思います。

継続的インテグレーション

ここでは、いわゆる CI (Continuous Integration: 継続的インテグレーション) のお話です。
CI用のソフトも色々あります。

ここでは、Python製自動テストサーバーBuildbotの紹介です。
Python が動作する環境なら動かせます。

詳細はPython開発合宿2008冬の資料をもとに説明されました。

基本的な流れは、

テスト書く
テスト通す
コミットする
フックする
buildbot走る
エラーだと通知やパトランプ

といった使い方。
複数人共同でソースを書いて行く場合は、だれかのコミットが他に影響したことを知るために、こういった継続的統合の手法が有効です。

構成としては、buildMasterというのが統合の集中管理をしており、buildSlaveの管理や、結果通知等をしているようです。
また、buildbotは色々なvcsに対応しています。

こうした柔軟性から、Buildbotは多くのOSSプロジェクトで採用されているようです。

Buildbot, Python, Webkit, Mozilla, Google Chromium XEmacs, MongoDB, Wireshark ILM, 
Boost, Zope, Twisted, SpamAssassin, OpenID, KDE, GHC, Subversion, OpenOffice, Jython ...

BuildbotやPython本体はもちろん、WebkitやChromium,XEmacs,等そうそうたる顔ぶれです。その実力が伺えます。

ドキュメント作成の自動化

ドキュメント作成はさぼってしまいがち

向かうにつれて時間がない
文章を書くのが苦手だ
見ない文章は書きたくない

という状態を

ドキュメントを書くのは楽しい！

プロジェクト開始時にプロセスを整備
必要な文章を必要な時に書く
ソフトウェアコード同様に成長させていく

という方向にもって行くのが大切。

そのために、「ドキュメントを書くのをもっと簡単に！」するためのツールとして、Sphinx というツールの紹介です。

SphinxはPyhtonで作られたドキュメント生成のツールです。reSt(reStructuredText)というwikiのような記法で記述します。
ソースのビルド時に、ドキュメント間のリンク生成や、強力なコードのシンタックスハイライトを使って見やすいドキュメントを簡単に作れます。
また、作成したドキュメントは、HTMLやPDFだけでなく、ePubにしてiPad等で見ることも出来ます。
Pyhtonのdocutilsやpygment等の既存記述を上手く組み合わせて作られており、拡張もPythonで書くことが出来ます。

最近はOSSでドキュメント生成に使われたり、日本では翻訳プロジェクトでも使われているようです。

ドキュメントの生成は、"make"を使うので、"make html"を先ほどのCIで回しておくと、作成しながらすぐフィードバックを得ることが出来るとのこと。
また、ソースはテキストなのでバージョン管理もしやすく、セミラティス構造であるwikiに対して、Sphinxはツリー構造であるため、構造をシンプルに保つことが出来ます。
以上のことから、Sphinxは最終成果物として非常に利用しやすいそうです。

こちらについては、
Shibu's Diary: Sphinx紹介セッション@BPStudy #30に渋川さんの紹介資料が有ります。

課題管理システム

複数人でプロジェクトを進める上で、バグや課題等を管理するシステム(プロジェクト管理) が重要になります。
PythonだとTracが有名です。(他にはRedmineとか)

Trac = wiki + 課題管理 + コード管理

Tracを使った作業フローはこんな感じです。

だれかがチケットを書く
担当者がAcceptしてコードを修正
修正をコミット
コミットログが自動で同期される
チケットをclose
ノウハウ等をwikiに記録し共有

この時、チケットやコミットの動きはTrac上のTimelineという画面で流れを追うことが出来ますし、
チケット登録時の#idを使って、コミットと実装をひもづけたり、wikiとリンクを貼ったり出来ます。

プロジェクトで出てくる様々な課題に関する情報が一元管理出来て、さらに必要な情報が繋がっている(散らばっていない)ということで、プロジェクトを円滑に進めることが出来ます。

全てを一つに繋ぐ

ここまでに出て来た

ソースコード管理の自動化
テストの自動化
環境構築の自動化
継続的インテグレーションの実施
ドキュメント生成の自動化

これらを全て、自動化し連携させる。

「これ全部Pythonでできるよ！」

というお話でした。

質問タイム

会場からの質問と、清水川さんによる回答です。

Q1: テスト周りがRuby等に比べると遅れてるという理由は？

A1: Unitttestの文化はある、しかし他の言語は「自然言語の文脈からテストを行う」と言った領域にも挑戦している（rubyだとcucamber）pythonにはそういうのがないなぁ。

Q2: ソースを分散VCSで管理した場合、どうやってCIするの？中央集権型の方が良くないか？

A2: 分散型であっても、ずっとバラバラなままではなく、最終的には一つに纏める。Mercurialでも中央サーバにあたるものを一つのcloneに位置づけて、そこでCIを回す。その点、「どれを中央サーバにするか？」などの運用ルールはその都度決める必要が有る。

Q3: Sphinxで他の文書をinport,exportする仕組みはある？別のドキュメントやtracのwikiとか再利用したい。

A3: 今は、頑張ってパースをかけるしかない。しかし、HTMLとかは構造化文書なのでパースが書けやすいし、Word等もHTMLで出せるから出来なくはない。手動でやらなくても、そういうサービスをしてるサイトもある。DocBookというのもある。あとTrac はwikiにreStを使うことがでいるので、reStで書いておくと後で使い回せる。

おまけ

今回のプレゼンは、Sphinxを変換してid:amachang謹製のS6というHMTLプレゼンツールで書かれています。
(S6の詳細はこちら)

感想

今回は、Pythonを用いたプロジェクト自動化の各ツールを横断的に紹介+デモという内容でした。
ツール自体がPython製なだけで、多くのツールはPythonを用いた開発でない場合でも十分に通用するものです。
開発に集中するために、プロジェクトの最初の段階でこういった環境をきちんと構築してしまうと、そのあと多くの場面で恩恵を受けることが出来ると思います。

もし一度に全部を導入するのに敷居の高さを感じるのであれば、個人的にはソース管理のMercurialやドキュメント作成のSphinxあたりから初めて見るのが良いのではないかと思います。(テストは、もう書いてますよね？w）

今回は概要でしたが、もっと詳しく知りたくなったら、清水川さん他４名による以下の翻訳本を読むことをお勧めします。冒頭にも有りましたが、Pythonの話だけでなくXPの話が多く出てくるので、Pythonユーザ以外にもお勧め出来ると思います。(再掲)