これまでに使用した最適な導入環境について説明してください[終了]

ジョエルテストは質問を含みます：

ビルドを1ステップで作成できますか？

これは重要ですが、展開プロセスのいくつかはどのように合理化されているのでしょうか。

シュリンクラップからWebまでのすべてのソフトウェアが適用されます。これまでに作業した中で最も優れた展開環境は何ですか、またどのような手順が必要でしたか？

それは私が私の会社で設定した環境であり、現在取り組んでいます。

環境の説明

私たちはJavaデスクトッププロジェクトに取り組んでいる4人の開発者のチームです。ソースコードはMercurialの下にあり、メインのリポジトリは開発サーバーでホストされています。Mercurialでの作業には、主にTortoiseHgを使用します。私たちがオープンソース化したプロジェクトはBitBucketにあります。プロジェクトはMavenでビルドされています。私たちが使用するIDEはNetbeansです。これはMavenで非常にうまく動作します（Mercurialでも動作します）。

開発サーバーは、MavenプロキシリポジトリであるArchivaを実行します。プロジェクトのビルドにはmavenを使用しますが、プロジェクトの実行（mvn exec）、生成されたアーティファクトのArchivaへのデプロイ（mvn release）、およびArchivaによってホストされるアーティファクトからのアセンブリー（mvnアセンブリ）にも使用します。

我々は持っているRedmineのは、あまりにもバグトラッカーを、そして、それはMercurialのリポジトリを認識しています。私たちはRSSクライアントを使用して、プロジェクトの活動（RedmineとMercurialからの）を通知されます。メッセージとファイルを相互に送信するJabberサーバーもあります。

Hudsonサーバー（継続的インテグレーション）とSonarサーバー（コードメトリック）をセットアップしました。しかし、実際には使用しません。

WindowsまたはLinuxを選択できます

リリースを作成する手順

バージョン1.1.3をリリースする例

# tags the VCS, updates all the version numbers in the maven config file
mvn --batch-mode release:prepare -DreleaseVersion=1.1.3 -DdevelopmentVersion=1.1.4-SNAPSHOT
# performs a clean build, runs all tests, deploys to the server
mvn release:perform
# creates a unique jar (the final product) from the previously deployed artifacts (no recomilation involved)
<update the version number in a config file to 1.1.3>
mvn assembly:assembly

私が使用生地を私の新しいスタートアップで、セットアップの展開に。

ライブサーバーの更新は次のように簡単です。

fab prod upgrade

これにより、最新のソースがすべて取得され、メンテナンスページが表示され、データベースが移行され、新しいコードが設定され、すべての依存関係が取得され、すべてが停止/開始されます。関連するすべての情報（パスワード、ユーザー名など）はすべて事前に尋ねた。

コマンドを実行して情報を入力し、コーヒーを飲みに行きます。私が戻ってくるまでにすべてが生きている。

これについてJoelに同意するかどうかはわかりません。

Hudsonを使用して、ビルドをスクリプト化し（MacとWindowsの両方で継続的に）、実際のボックスを実際に発送する数回のインストーラーとCDイメージのビルドを含めます。常にQAのインストーラーからテストします。

また、Hudsonを使用して、インストーラーをライブWebサイトの「ベータ」エリアに1日に1回コピーします。

そのため、基本的には、ユーザーに毎日何の手順もなく展開できます。公式リリースを作成するときは、CMSでインストーラーのファイル名を切り替えて、現在のベータインストーラーをリリースインストーラーにし、Antビルドスクリプトを変更して新しいバージョン番号（新しいベータ版になります）に切り替えます。

これを設定して機能させることで、リリース日は完全に非イベントになります（これはまさに本来あるべき姿です）。発売日を間違えてしまいました（以前は定期的に発生していました）！

私のクライアントの1つでは、Railsで作業し、デプロイがgitからプルされるようにすべてを設定しています。ただし、Railsであるため、「ビルド」はしません。

したがって、展開プロセスは次のようなものです

git checkout review
git merge whatever-that-was
git push
cap review deploy:migrations

カピストラーノとGITのミックスはかなりうまくいきます。

もちろん、これらの手順の一部をスキップするために、さらにスクリプトを記述します。

私の現在のワークフローはこのようなものです。

1. ローカルVMで開発する
2. テスト、変更のコミット、githubへのプッシュ
3. EC2にsshして変更をプルする

これはすべて1つのステップにスクリプト化できます。

Java Web Startアプリケーションがあります。ユーザーが要求したときに要求されたURLにJNLPファイルが適応されるように、デプロイメント手順をWARファイルとして再構築します。

非常にスムーズに進むと思います。

最近はgitをよく使っています。デプロイをgitリポジトリに登録して、実行するバージョンをチェックアウトするようにgitに要求するというアイデア。バックグラウンド更新、実際のファイルを更新するための非常に短いチェックアウト時間、問題が発生した場合に前のバージョンにロールバックするための非常に短いチェックアウト時間。それは私たちにとって非常にうまく機能すると思います。

これは今ではかなり古くなっていますが、私は以前、コードを何ヶ月も前にデプロイするための手順として、私が持っている中で最高であることがわかりました：

1. コードの変更をVisual SourceSafeにチェックインします。
2. 上司のマシンで最新バージョンを取得します。
3. いくつかのDLLを生成したソリューションをコンパイルします。
4. 新しいコードが期待どおりに機能したことを示します。
5. 本番サーバーをインターネットから切断して、干渉なしに更新します。
6. バイナリーを実動サーバーにコピーします。
7. IISを起動します。
8. 使用しているISDN回線でインターネットにリダイヤルし直します。

これは、1990年代後半に、ドットコム用にNT 4.0上のVisual C ++でプログラミングをしていた頃のことです。これまでの展開プロセスのほとんどは、負荷分散された運用サーバーの処理など、nAntタスクやその他の追加の処理が複雑になったのに対し、当時の運用ボックスは1つだけでした。

プロセスをリリースエンジニアに引き渡すコースの方が優れていますが、コードを実際に公開する場合とはまったく異なります。

何の理由もなく、ASP.NET Webアプリを右クリックして[公開]を選択するのは、アプリを展開しなければならないときにうれしい驚きでした。確かに、IISで仮想ディレクトリなどを事前に設定する必要がありましたが、新しいバージョンの展開は数クリックで済みます。