ソース管理への移行

私たちの会社はかなり小さな会社（3〜4人のプログラマーと3〜4人のサイトデザイナー）で、約100以上のWebサイトに機能を提供する単一目的のPHP Webアプリを開発しています。私たちは、かなりうまく機能している別の開発環境と本番環境で数年間運用してきました。開発者が開発するのに十分な個別の機能が常にあるため、プログラマーが実際に衝突することはなく、ソース管理なしで作業する方が便利でした。データ損失のリスクがあり、不注意による移動でファイルの公平な共有が失われても、

もう1つの考慮事項は、デザイナーが技術に精通していないことです（WYSIWYGを使用する代わりに、HTMLマークアップを紹介しました）。これは、バージョン管理への移行をためらう理由の1つです。

しかし、100以上のサイトに到達し、開発チームが成長している今、手順とソース管理を標準化しようとしているところ、プログラマーにとっては論理的なステップのようです。これにより、パッチの展開もスピードアップすることを期待しています。

残念ながら、私はソース管理システムをセットアップする経験が非常に限られています。同様の設定、または切り替えの経験のある人から聞いて知りたいことは何ですか。

1）すべて（サイト、CSS、HTMLテンプレート、アプリコード）をバージョン管理し、設計者にバージョン管理を習得させますか？それとも、アプリケーションコードに取り組むのは開発者だけですか？

2）ソース管理を最初にセットアップするときに注意すべき落とし穴は何ですか？

3）devの配備=>ソース管理のための本番のヒント。

すべての洞察をありがとう。

編集1：ダン。これまでのところ、すべてを制御することをお勧めしています。それは私が私の髪を早く失うことになるでしょう。それはおそらく近い将来に新しい質問を引き起こすでしょう。これまでのアドバイスをありがとうございます。

編集2：良い答えがたくさんあります。さまざまなバージョン管理システムを調べます。皆様のご返信ありがとうございます！

デザイナーであっても、すべてにバージョンを付けると役に立ちます。そして、良いトレーニングでうまく実装されれば、面倒なことよりも役立つと思うでしょう。

始めたばかりの場合は、gitやmercurialなどの分散バージョン管理システムを使用することを強くお勧めします。これは世界の一般的な傾向であり、多くの利点があります。切断モードで作業するのは簡単で、ネットワークに依存せず、バージョン管理下でプライベートで洗練されていない作業を実行し、準備ができたらすべてを一元的にチェックできます。

そして、権威や何かに訴えることに頼るのではなく、このトピックについてジョエル・スポルスキーが何と言っているかをチェックしてください。（選択引用： "Subversion = Leeches。MercurialおよびGit = Antibiotics。"）とりわけ、彼はこれらの新しいシステムが従来のバージョン管理とは異なる新しいメンタルモデルを使用しているという興味深い点を述べています。最初からのアプローチは勝利です。

私はすべてをバージョン管理下に置くと言います。すべてうまくいったら、タグにコピーできます。ほとんどのSCMシステムでは、サーバーに多くのディスク容量は必要ありません。

最初の落とし穴に関する限り、それほど心配する必要はありません。すべてをサーバーにコミットし、正しくない場合はそれをシャッフルして、後で余分なものを削除できます。私がコミットしない唯一のことは、ソースからビルドされたアーティファクトです。つまり、Javaコードファイルはバージョン管理に属しますが、コンパイルされたクラスや「ソースからビルドされた」バイナリのISO / DVD全体には属しません。

開発から本番への移行は簡単で、主要なマイルストーンごとにブランチを作成します。バージョン管理システムのディレクトリレイアウトは通常、次のようになります。

/ trunk / project / branches / project / version1 / branches / project / version2 / branches / project / version3

したがって、製品のバージョン2にバグを見つけ、そのブランチに移動して修正し、バージョン2.1をリリースするとします。新しいバージョン4の/ trunk / projectフォルダーで作業している間、どの機能を後方と前方にマージするかはユーザー次第です。

SCMのクールエイド飲みに騙されないようにしてください。一般的なバージョン管理システム、つまりSubversionとGitの機能的な違いはほとんどありません。チームにとって最も重要なことは、それらのサーバーが既存のツールとどの程度うまく統合されるかです。私はWYSIWYGも好きではありませんが、eclipse-phpやサーバーと互換性のある他のIDEを用意しておくと便利です。

私は開発者で、以前はIT管理者として働いていました。

特定の質問に答えるには：

1）はい、すべてにバージョンを付けます。

2）人々が学習できるように、ダミーのバージョン管理リポジトリとダミーのプロジェクトを設定することを提案します。

3）本番環境に配置されるバージョンにタグを付けます。裁判さえ。その後、いつでも誰かが実行している特定のバージョンをチェックアウトできます。

質問CVSにタグを付けました。

私の提案は、代わりにSubversionを真剣に検討し、TortoiseSVNと組み合わせて非常に使いやすくすることです。TortoiseCVSもあります。

バージョン管理に関する社内チュートリアルを実行することをお勧めします。あなたの開発者/デザイナーがこれにこれまで遭遇したことがないのであれば、私は驚かれます。亀はそれを非常にユーザーフレンドリーにします。

また、Webインターフェイスの1つをCVSまたはSubversionにインストールすることも有益です。

CVSでの転覆を提案する理由は、CVSは非常に優れていますが、設計と実装に深刻な問題があるためです。私にとっての最大の利点は、次のとおりです。1）ディレクトリをバージョン管理することはできません。3）アトミックコミットはありません。4）コードストアから手動で削除しなければならなかったため、ロックファイルがめちゃくちゃになって残されていることがよくあります。ロックファイルをrmしたため、これを行う際に破損の余地がありました。5）SSLサポートとユーザー/パスワードの管理

Subversionは基本的にこれらすべての問題を修正しますが、おそらく他にも多くの問題があります。また、エクスターナル（実際に使用します）などの高度な機能も多数備えています。そして、ユーザー/グループをActive Directoryにリンクすると、便利な場合があります。当時は利用できないCVSを使用していました。今かもしれない、私はチェックしていません。

おそらく、svnを使用する上で最大の違いは、タグを作成しないことです。代わりに、プロジェクトディレクトリがTagsフォルダーにコピーされ、名前が付けられたコピーのように見えるものを作成します。ドキュメンテーションを見てください、そしてあなたは私が何を意味するかを見るでしょう。奇妙に見えるかもしれませんが、あなたはそれに慣れています。

このウェブサイトはいくつかの利点があるかもしれません（私はそれを保証することはできません）：phpウェブサイトのモジュラーsvnリポジトリの設定 http://www.howtoforge.com/set-up-a-modular-svn-repository-for -php-websites

そしてそれは-の上に表示されます知恵の多くの偉大に関してですが賢明-バージョン管理の展開監視システムの展開のようなものです。私のクライアントは「何を監視すべきか」と言っており、明白な答えは「すべてを監視する」です。しかし、これは歓迎すべきニュースではありません。350のシステムがあり、それぞれに20〜30のシステム変数と一連の用途固有の変数があり、それらはすべて便利に監視できます。でも私はたった一人で、彼らは二週間の間にいくつかの結果を見たいと思っています。

したがって、ベストプラクティスはすべてをバージョン管理することであることに同意しますが、これが最初に実用的でない場合は、制御の欠如がこれまでほとんどの問題を引き起こしていたものを管理することから始めます。

ほとんどの停止がアプリケーションコードによって引き起こされている場合は、それを制御することから始めます。ほとんどが計画外のCSSパッチによる場合は、それを制御します。等々。

これにより、時間の投資に対する最高の利益が得られるだけでなく、将来的にバージョン管理の使用を拡大するための正当な理由が得られます。「アプリケーションコードにバージョン管理を追加したため、計画外の停止が30分を超えました。 1か月あたり11か月から2に減少しました。これら2つは静的なHTMLの変更が原因で発生したため、次にバージョン管理する予定です。」

段階的なロールアウトは、組織内の熟練したユーザーにも提供します。はい、6人のアプリ開発者全員にシステムの使用方法を教える必要がありましたが、彼らは学んだので大丈夫です。システムをCSSチームに展開する時が来たので、3か月前よりも6人の社内エキスパートがいます。この時までに改宗者がいるかもしれません。有害な変更を即座に取り消す機能によってお尻を救われた開発者は、CSSチームにとって最高のエバンジェリストとなるでしょう。

編集1：このルートに行くことにした場合、チップとして安いバックストップは、少なくとも製造ボックスの上にトリップワイヤーを追加することです。そうすることで、Things Breakが現在の責任ではないとVCSが言った場合、 変更点をすばやく特定できます。これにより、修正が迅速化され、バージョン管理の次の候補が提案されます。

すべてをバージョン管理します。コントロールされていないCSSの変更のために、HTMLファイルをバージョン管理下に置き、サイトを完全に台無しにしても意味がないため、簡単に元に戻すことはできません。

落とし穴：私は、バージョン管理の使用がかなり制限されている間、個人的には遭遇していません。

展開：現在、WindowsボックスでホストされているSubversionを職場と自宅の両方で使用しています。Windowsが利用できるのはそれだけだからです。それ以外の場合は、別のOSと同じくらい簡単にできました。技術者以外のユーザーにとって、インポート、エクスポート、コミット、差分などを処理するためのシンプルなGUIベースのツールを提供するための鍵です。使用するツールは、使用するOSとVCSシステムによって多少異なります。

使用：コードを変更するときは、テストとコミットを頻繁に行います。これにより、失敗したときに必要なだけ戻ることができます。さらに、さまざまなリビジョンを比較し、コードの一部をコピーすることで、コードの別の部分の一部を修正するために以前のバージョンに戻す必要があるため、すべての変更を失う必要はありません。

追加された利点：VPNまたは安全な接続を介してソースリポジトリへのアクセスを許可できるため、ユーザーは自宅やどこからでも作業できます。例えば、私は家でアイデアを得て、そこで仕事のコードを編集し、その後、考えを失う前に編集するかもしれません。

すべてをバージョン管理します。

展開は、これらのサイトごとに「カスタマイズ」する必要がある量によって異なります。1つまたは2つの構成ファイルを除いてそれらが同一である場合は、コードのコピーをチェックアウトして、小さな変更を加えることができます。必要に応じて、クライアントごとにバージョン管理の更新コマンドを実行します。

「顧客のサイトに直接チェックアウトする」配布モデルを使用する場合、ユーザーがhttp://example.com/を閲覧できないように、サーバーがバージョン管理ディレクトリへのアクセスを確実に除外するようにする必要があります。 git /と内部を覗いてみてください。また、私はでしょう間違いなく、サイトの更新がゴチャゴチャに行かないことを確認するために、各クライアントのためのテストと生産のVirtualHostを持っています。特に、個々のクライアントのファイルにカスタムの変更を加える場合は、変更を有効にする前に競合を処理する必要があります。この場合、テスト仮想ホストをチェックアウト/更新し、すべてが正常に機能したら、テスト仮想ホストを本番仮想ホストにコピーします。

何をバージョン化するかについて人々が言っ​​ていることはすべて良いことです。

Subversionを使用する場合は、Bitnami Tracスタックを試すことをお勧めします。 http://bitnami.org/stack/trac

Subversionの設定を簡素化し、変更とバグを追跡するための発券システム（この段階で使用するかどうかを選択できます）、および開発者に使用方法を文書化するために使用できるWikiが付属していますシステム。

すべてのWindows開発者にTortoiseSVNを提供してください。みんなにいくつかのsvnコマンドラインの基本を教えます。

結局のところ、ツールは開発者に組み込む必要のある考え方よりも重要ではありません。うまくいけば、バージョン管理が良いものであることがすぐにわかり、作業の損失を防ぎ、既知の良好な状態に戻らない行き止まりから戻ることができます。（わずかな）オーバーヘッドを上回るメリットがあります。