開発運用って難しい

プログラミングを勉強してきて、そこそこのアプリケーションは作れる様になった。

今の会社に入るまでは、ずっと1人で作業して来た。
その間、コードを管理するのはローカルPCで、情報も簡単なメモと自分の頭でどうにかして来てた。
そのつけが今大量に降り掛かって来ている。
CVSでコード管理して、アプリケーションのアップデートを自動化して、テストを自動化して。
大半は上の人がやっている事なんだけど、どうにも目が回る。

と、言う訳で、頭を整理するのにちょっとメモ。
PHPの場合が中心にあるので注意(スクリプト言語はほぼ同じ?)。
下っ端駆け出しの考えなので、最大限注意。

情報共有
チームで開発する場合、特定の人物にしか分からない情報があるとよろしくない。
そうすると、ドキュメントを作ってそれを誰でも取り出せるところに置かないといけない。
そこで、"wiki"の出番がやってくる。
ネットワーク上にあってwebブラウザから見る事が出来れば、誰でも情報を取得できる。
テンプレートと文法のおかげで、まとまりのあるドキュメント作りも可能。
大抵はフィード出力にも対応してるから、更新情報も簡単に手に入れられる。
名前空間のサポートも大きい(カテゴライズが簡単)。
などなど。

コード管理
色々問題があるらしいけど、ノウハウとか枯れさ具合とかからCVSが有名。
ファイルのバージョンを自動的に管理してくれて、履歴も記録してくれる。
何かあったときも前の物を取り出せるし、バージョン間のdiffもとれる。
これも、ネットワーク上に置けるから共有が簡単(というか、それありき)。
現行バージョンの仕様から外れたこと(機能変更・追加とか)をする場合、ブランチを作れば安心(開発の流れを分ける)。
1つのファイルを複数人が変更した場合、衝突が起きるけどある程度はマージしてくれる。
diffとかをうまく使えば(使えれば)、マージも何とかなる。
チーム開発でなくても、アプリケーションを長期間運用するならCVSの恩恵はでかい(CVSに限らないけど)。

ユニットテスト
オブジェクト指向の場合、アプリケーションはクラスの集合(かな)。
アプリケーションの仕様についてもそういえる訳で、クラスの仕様をまとめるとアプリケーションの仕様になる(かも)。
インターフェースが決まっている場合、テストは作り易い(何を入力したら何が返ってくるか分かる)。
で、テストってのは確実な仕様書になる訳で、クラスを実装する前にテストを作るのはとてもよろしい(らしい)。
クラスのテストはユニットテストと呼ばれていて、PHPの場合はPHPUnitが有名。
テストを最初に作れば、目標が明確になるし実装後にも仕様が変わらない限りずっと使える。
テストが活躍するのは開発段階だけじゃなくて、リリースの際にも頑張ってくれる(動作保証・依存チェック?)。
PHPUnitはコマンドラインで実行できるから、リリース作業が自動化される場合にも組み込み易い。
そんな感じで、テストを作るのはとても重要(守れてなし)。

構築
単純に考えれば、CVSのexportでがっつり上書き。
設定ファイルとかで、環境ごとに異なる物がある場合は要注意。
例えば、テストサーバと本番環境とか、クラスタリング環境(?)とか。
オーナーとかパーミッションとかの権限周りもCVSだけではカバーできない。
となると、CVSから持ってくるところからまとめて自動化スクリプトあたりで実行。
で、シェルスクリプトとかでもいいんだけど、何か便利なツールがあると定型的に作る事が出来て便利。
Phingとか言うのが、なんだか素晴らしい世界につれて行ってくれそう。

自動テスト
ユニットテストはクラスのテストで、それとは別に全体のテストも必要。
全部を掛け合わせたときにしっかりと動いてくれるかを確認したりする。
HTTPベースで行う場合、JMeterがいいかも(これ以外は触った事無い)。
seleniumを調査中だけど、使った事が無いので何とも言えず。

バグ管理/タスク管理
テストやユーザからの報告などで、バグや要望などが出てくる。
これを管理するのに、BTS(Bug Tracking System)というシステムがある。
影舞というBTSしか知らないんだけど、まあ基本としてネットワークを介して情報を管理/共有できるツールのはず。
各レポート(個別案件)にステータスをつけられるので、該当レポートが今どうなっているとか管理できてかつ共有できる。
BTSへのレポートをMLで流せば便利になって、フィード出力対応とかしてると特定範囲の情報が管理し易くなる。
影舞の場合、フィード出力は全体しか対応してない(?)っぽい(使った感じ)。
こういう情報は一元管理する事が大事で、あっちこっちに置き場があるとどうしていいか分からなくなる。
最悪、放置されっぱなしのレポートが出てくる。
管理するにはルールとか補助ツールが必要な訳で、BTSは見事に解決してくれる。


ざっと思いついたまま書いても、これだけある。
まだまだ守りきれてない部分が多々あって、リリース作業時が大変。
迷惑かけ通し。
型にはまって、慣れてしまうまでが凄い大変。
ただ、しっかりと守ればリリース作業が定型処理になって自動化が簡単になる。
自動化すると、そこに不確定要素が入りずらくなる訳で、安全性が増すし何より楽できる。

開発運用のノウハウがあったり、きっちりしたスタイルを確立すると、開発が順調になって応える力も大きくなる。
まあ、こういう機械作業だけじゃなくて、プロジェクト管理とかもっと必要で重要なところはたくさんあるけど、個人的にここが最重要。

# Phing
Do You PHP? - Phing2 - PHP版Ant for PHP5
JAVAの開発環境として有名(常識?)らしい、『Ant+JUnit+ JCoverage』をPHPに適用するパッケージ(?)。
外部コマンドを実行できるらしいので、『cvs+Ant+JUnit+JCoverage+scp/ftp/rsync』も狙えそうという事。
一貫したスタイルが確立できそう。

プロフィール

このブログ記事について

このページは、koshigoeが2005年10月 5日 21:03に書いたブログ記事です。

ひとつ前のブログ記事は「FeedBurnerとFeedBlitz」です。

次のブログ記事は「FeedBlitzは続けられなそう」です。

最近のコンテンツはインデックスページで見られます。過去に書かれたものはアーカイブのページで見られます。