Server(TFS)を使った時の雑感をまとめてみました。昨日のワンクリックデプロイ勉強会にインスパイヤされて書きました。参考になりましたら幸いです。アンチパターンも含まれていますので反面教師にして頂ければと思います。プロジェクトの性質6ヶ月で要件定義から試験までやってリリース。開発チームは最大8名で年度末に解散。R&D的な取り組みなので要件はほとんど見えておらず、最初の1ヶ月でプロトタイプを提供して本当にやりたいことを検討した。(これ以上は割愛)アジャイルではない。一括請負契約のウォーターフォール。顧客にはリッチクライアントアプリを提供した。2010短時間でCI環境を構築できるメリットは大きい。Serverを使える人ならTFSを管理できる。R2その辺に転がっているPCを使うのは望ましくない。継続的な運用を考えると、速くて安心できるマシンが必要。当然ながらデータバックアップや代替機の用意も必要。当初は別案件との兼ね合いでSubversionを使っていたが、途中でTFSに移行した。チェックイン、チェックアウトの操作に慣れればSubversionとあまり違わないと思う。説明資料は作らなかった。分岐とマージについては説明資料を作った。将来のバージョンで、Git+SVNのように分散バージョン管理の美味しいところを取り入れてくれたら嬉しい。決めごと(暗黙も含む)基本的にはタスクごとにチェックインすること。チェックインは必要に応じてタスクやバグと関連付けること。TFSはチェックイン時に関連付けるバグを選択できるので便利。バグIDを手入力したりする必要はない。最低でも1日1回チェックインすること。最初から全部作ろうとして抱え込んでしまう*1人がいたので、少しずつ書いてチェックインしてもらうようにした。手に負えなくなったコードはシェルブして質問に来てもらうようにした。シェルブいろいろ使い道があると思う。Gitのローカルブランチみたいに、ちょっと大きな変更を途中で保管しておくのにも使ってた。他人がシェルブしたコードも見られるので、質問や議論のネタを入れておくのにも使ってた。席が遠いと困るよね*2。チェックインポリシービルドの通らないコードはチェックインできない。ユニットテストの通らないコードもチェックインできないようにしていたが、諸々の問題で運用が回らなくなったので制約から外した。負けだと思うけど現実を見たほうがいい。ゲートチェックインも使ってみたが諸々の問題で運用できず。デプロイメントリリースワンクリックCD-Rリリース。世の中にはインターネットにつながらない世界が存在する。ビルドサーバの共有フォルダにバイナリを出力するようにして、リリース時は共有フォルダを丸ごと焼いて顧客拠点に持っていく運用にした。顧客端末へのリリースは人力でやるしかなくて、煩雑な手順が問題になった。デプロイしたバージョンにはラベルを付ける。ブランチラインの運用TFSの「分岐」という用語は分かりにくいと思う。これは6ヶ月のプロジェクトが終わってからの話だけど、前年度の保守と次年度の開発が並行して走ることになったのでブランチを分けた。どのブランチで作業しているかを分かりやすくするため、コードツリーの上位(正確にはソリューションのフォルダ)にブランチ名の付いた空ファイルを放り込んでおいた。継続的インテグレーションビルド夜間ビルドのみ。当初はチェックインごとにビルドしていたが、ビルドサーバが過負荷になって他に影響が出たので泣く泣くやめた。問題の発見が遅れるのでアンチパターンだと思う。ビルド通知ツールを入れておくとビルド結果がバルーンで表示されるようになる。当然ながらテストが失敗すると赤くなる。赤い日々を過ごしてはいけない。赤くなったら騒ぐ人は必要。環境が原因の場合は切り分け調査に時間がかかる。ビルドされたバージョンには自動的にラベルが付加される。変更がない日はビルドが実行されない。成果物ビルド結果は共有フォルダに保管する。ように出力先を細かく設定できる。静的解析とかカバレッジとか黄色い日々を過ごしてはいけない。黄色があると慣れてしまうので撲滅する文化が必要。レポートを上手く使いこなせなかった。Expressを組み合わせると、開発環境でアプリを実行するときにデータベースファイル(MDF)を自動的にアタッチして実行してくれる。開発端末のデータベースを同一に揃えることが可能。数百MBのMDFファイルをリポジトリに入れていた。リポジトリサイズが大きくなるとビルドプロセスが重くなる。そのため、ビルドサーバでビルドする時にMDFファイルの作業コピーを作らないように設定した。自動ビルドで残す世代を制限しないとディスクスペースの消費が激しい。本番環境データベースファイルをCD-Rに焼いておき、現地で配置する。事前に用意したSQLを流す。マスターデータが変わるのは法改正みたいな特殊な世界だったので参考にならないと思う。ユニットテストユニットテストの実行時に接続文字列を変更し、空のMDFをアタッチしてテストを実行するようにした。テストケースごとにデータベースを空にする。Serverに接続する必要がある。まとめ短時間でCI環境を構築できるメリットは大きい。TFSのインストールや管理は簡単。TFSのソースコードリポジトリは使いやすい。ビルド結果はビルドサーバの共有フォルダに出力するのがおすすめ。リポジトリにデータベースファイルを入れておくと、開発環境の管理がとても楽になるし、環境に起因する問題が激減する。ビルドエラーや警告から目を背けて赤い日々や黄色い日々を過ごしてはいけない。凄腕プログラマーになりたい。*1:1メソッドが数千行になってて驚いた。*2:請負契約や準委任契約の問題。Requestを作成する2020-01-20アプリケーションの開発フローとGitOpsArchivesSearchはてなブログをはじめよう!int128さんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。