バージョン管理ソフトウェアを使用したことがない開発者を納得させるには、開発者が抱くあらゆる質問、心配、疑問に答える準備をしておく必要があります。次のような質問が殺到します。
- 以前の働き方の何が問題だったのでしょうか? トラブルは一度もありませんでした！(さらに詳しく調べると、彼らが持っていたが都合よく忘れていた、または問題として認識していなかった、あらゆる種類の問題について聞くことができます)。
- どのようにして私たちのものをサイトに展開しますか?
- 私の物はどこに保管されていますか？
- 簡単であるべきことを行うのに、なぜこれほど多くの余分な手順があるのでしょうか?
- どうして私の邪魔をするの？仕事を終わらせるしかない！
リンクした質問に対する受け入れられた回答は、良いスタートです。次のことを実証する必要があります。
- 開発者へ: これはいつかあなたの皮を救います。
- マネージャーへ: プロジェクトで誰が何をしているかを正確に追跡できます。
- 経理担当者へ:セイフティ ネット (物事がナシ型になった場合に備えて) を用意し、開発者をデプロイせずに開発し続けることで、最終的には時間 (したがってお金) を節約できます。
- システム管理者へ: これにより、開発者はサーバーから離れることができます。
バージョン管理 (Subversion など) をインストールするだけでは終わりません。人々は以前のやり方に戻るでしょう。なぜなら、その方が簡単だからです (おそらくそうではないでしょう。単に慣れ親しんでいるだけです)。ワークフローと追跡要件をサポートするために、ソースと構成の管理と設計プロセスを理解する必要があります。
少なくとも 2 つの完全に分離した別個の環境 (開発と運用)、できれば 3 つ (開発、ステージング、運用) がありますよね? そうでない場合は、そこから始めてください。ライブ Web サイトを無作為に変更するべきではありません。また、可能であれば、開発者は自分のワークステーションから直接プロジェクトを実行できるようにして、チェックインする前にテストできるようにする必要があります。
アプリケーションは完全に自己構成する必要があります。つまり、それらを特定の環境にデプロイするたびに手動でいじる必要はありません。展開は、多かれ少なかれ「手放す」か、少なくともスクリプト化する必要があります。セットアップが完了したら、展開を処理するために、独自のスクリプト、継続的インテグレーション システム、またはその両方の組み合わせが必要になります。
post-commit フック スクリプトを使用して、開発環境で Web サイトを更新できます。そのため、開発者が変更をコミットするとすぐに、開発者サイトに移動して確認されます。
したがって、私自身のセットアップは次のとおりです。
- CruiseControl.NET は、デプロイ先の各サーバーで実行されます。
- コミットすると、開発サーバー上の CCNET サービスが変更を取得し、プロジェクトを SVN から取得し、コンパイルして Tomcat アプリ サーバー (Java Web アプリ) にデプロイします。
- 展開が成功すると、CCNET は、展開したばかりのコードを表すタグをリポジトリに作成します。
- 独自のテストを実行した後、ステージング サーバーの CCNET 構成が更新され、開発者が作成したタグを指すようになり、ビルドが強制されます。
- ステージングでビルドが成功すると、別のタグが作成されます。
- 最終的な受け入れテストが承認された後、本番サーバーの CCNET 構成を更新し、ビルドを強制します。
- 本番環境でのビルドが成功すると、別のタグが作成されます。
私の CCNET 構成も Subversion に保存され、CCNET を介して展開されるため、サーバー上のファイルに直接触れる必要はありません。ファイルを更新し、コミットし、更新された構成をそのサーバーにプルする「ビルド」をトリガーします。
すべてのタグが私に提供するものは何ですか?
- 何か問題が発生した場合は、各環境を以前の既知の良好な状態にロールバックできます。
- 機能セット B の開発を進めながら、週の後半に予定されているメンテナンス期間中に機能セット A が本番環境に昇格するのを待つことができます。
RedGate の Deployment Manager などの他のツールを使用すると、これをさらに自動化できます。
これらすべてが機能するためには、誰もが従う、しっかりとした合意されたプロセスが必要です。また、職務を明確に分離することも有益です。開発者がデプロイする必要はなく、管理者がコードをいじる必要もありません。
OK、これですべての設定が完了しました。全員 (経営陣を含む) が参加したと言っています。次は何をしますか?
すべての開発者の非開発サーバーへのアクセスを取り消します。FTP も、シェルも、何もありません。ログがある場合は、一部のログへの読み取り専用アクセスが可能です。
彼らは泣き言を言うでしょう。彼らはうんざりします。彼らはあなたに腹を立てます。「あなたは私のすべてのアクセス権を奪っている!」「お邪魔します！」「これは単純な変更を行うのに 10 倍の時間がかかります!」「あなたはモンスターです！」「あなたはサタンを本当にナイスガイのように見せます！」
関係ありません。「より簡単な方法」がある限り、正しい方法は無視されます。これが、船上で管理し、後ろを監視する必要がある理由です。
ライブ トラフィックの負荷が大きすぎて、何かが初めて運用に移行し、データベース サーバーがダウンした場合、アプリの以前のバージョンに戻り、5 分以内に正常に戻ります。あなたは英雄になるでしょう。
「分岐する前に.svnエントリを削除する」必要があるとあなたが言っていることは、私にとって心配です。プロセスの説明が不十分であるか、何か間違ったことをしています。
編集：他のことを思い出しました。リポジトリのバックアップ戦略がありますよね? そうでなく、ドライブが故障してデータが失われた場合、故障したハードウェアではなく、すべてがあなたと Subversion のせいになります (ハードウェアの故障はどこでも発生する可能性があるにもかかわらず)。