9

現在、私が取り組んでいるプロジェクトは、完全な/使用可能な製品を作成するためにいくつかの手順を必要とする複雑さのレベルに達しています (実際には難解になっています!)。残念なことに、私たちはコンティニュオス インテグレーションの考え方から始めたわけではありません。そのため、時にはそのような苦痛を想像することができますが、クリーンでテスト済みのビルドを取得しようとして半日を簡単に無駄にしてしまうこともあるでしょう。

とにかく、巨大なプロジェクトと同様に、多くの異なる言語 (たとえば、エンタープライズ スタイルの Java や C# だけでなく) の多くのコンポーネントと、多くのグラフィックおよびテキスト リソースで構成されています。ここでの問題は、私が Continuos Integration を探すとき、新しいプロジェクトをゼロから開始することを想定したベスト プラクティスやテクニックを常に見つけてしまうことです。ただし、これは新しいプロジェクトではないため、Arcane Integration から Continuos Integration への移行を積極的に開始するための優れたリソースは何かと考えていました :)

前もって感謝します！

4

5 に答える 5

6

ここでは、2 つの単純な (hah) ステップで構成されています。

  1. 繰り返し可能なビルドに進みます。
    1. ソース管理を使用し、すべてのコードをチェックインします。
    2. ビルドに使用するすべてのツールを確立して文書化します (主に、どのコンパイラ バージョンか)。これらのツールの展開とセットアップのプロセスを反復可能にします。
    3. ビルドに必要であるがチェックインされていないリソース (サード パーティのインストール、サービス パックなど) を明確に確立し、文書化します。これらの依存関係に対して、反復可能なデプロイとセットアップのプロセスを用意します。
  2. ソース管理にコミットする前に、開発者は
    1. 作業コピーを更新する
    2. 正常に構築
    3. 自動テストを実行して合格する

これらの手順は、一度に 1 つずつ行うことができます。各ステージで特典を獲得できます。たとえば、ソース管理をまったく使用していない場合は、コードを (他に何もせずに) ソース管理に入れるだけで大​​きな前進です。また、自動化されたテストがない場合、開発者はそれらを実行できませんが、以前のコミットを取得して、コンパイラーに作業をチェックさせることはできます。

これらすべてを行うことができれば、あなたは素晴らしい正気の場所にたどり着くでしょう。

目標は、反復可能なビルド プロセスと、変更がビルドや他の開発者にどのように影響するかにプラグインされている開発者です。

次に、より高いコンプライアンスを確立することでボーナスを得ることができます。

  • 開発者は頻繁にコミットする習慣を確立します。作業コピーにあるコードは、1 日以上経過していてはなりません。
  • 自動化されたビルド プロセスは、チェックインのソース管理を監視し、結果をユーザーが受け入れることができる場所 (テスト環境、プレビュー Web サイト、ユーザーが見つけられる場所に .exe を配置するなど) に結果を取得します。
于 2008-11-19T02:27:43.877 に答える
3

象を食べるのと同じ方法 (一度に一口ずつ) ;-) 継続的インテグレーションには自動化されたビルドが必要です。それから始めましょう。各ピースの構築を自動化します。Ant または NAnt は、これを行うのに最適な方法です。各コンポーネントの構築を NAnt タスクにします。その後、システム ビルド全体でこれらの個々のタスクを集約できます。

そこから、展開や単体テストなどのタスクを追加できます。CI テクノロジを使用する場合は、NAnt ビルドに接続できます。

于 2008-11-19T02:11:54.157 に答える
2

まず、ビルドとテストを手動で行うために必要なすべての手順を書き留めることから始めます。その後、少なくとも古い方法でそれを行うためのガイドがあり、物事を書き留めることで、それを完全なプロセスとして見る機会が得られます。

次に、スクリプトを作成する部分を探します。

理想的には、コードコミットからビルドとテストをトリガーし、変更された部分のみを再構築して再テストします。おそらく、フルビルドとテストを毎晩または毎週行います。ログファイルまたはデータベースエントリと、ビルドの成功または欠如に関するレポートが必要になります。

ビルド済みの製品とオープンソースの独自のキットを検索して評価することをお勧めします。確かにすべてのスクリプトとレポートを自分で作成することはできますが、しばらく時間がかかり、ビルドシステムのコーディングではなく製品のコーディングが仕事であるため、レポートシステムはほとんど不十分になります。:-)

于 2008-11-19T02:39:42.807 に答える
1

移行は実際にはオプションではないと思います。中途半端なソリューションは状況を悪化させるだけです。

私のアプローチは、ビルド プロセスを理解しているクリエイティブ エンジニアを 1 人取り、座って「これを修正してください」と言うというものです。彼に1、2週間与えてください。

最終的な目標は、1 つの make コマンドで最初から最後まで実行されるプロセスです。

また、ネットワーク共有からチェックアウトしてバッチ ファイルを実行し、すべてのツールをインストールしてビルドするだけの自動化された「セットアップ」手順もお勧めします。新しいプログラマーを連れてきた場合、これによって全体的に節約される時間は驚異的です。ほとんどのプロジェクトは、新しいコンピューターにセットアップするのに 1 ～ 3 日かかります。そして、自分のシステムにインストールする際に何が起こっているのかを知らないのは常に「新しい」プログラマーです。

于 2008-11-19T02:09:53.397 に答える
1

要するに: 段階的に

さまざまなプロジェクトで機能するフレームワークを選択してください。

フレームワークにコンポーネントを 1 つずつ追加します。

フレームワークに慣れていない場合は、失敗するリスクを減らすために、最初にいくつかの簡単なコンポーネントに取り組んでください。

フレームワークを理解している場合は、より困難なコンポーネントや一般的に構築されているコンポーネントのいくつかに最初に取り組みます。これにより、チーム (および経営陣) が早期に利点を理解し、取り組みをよりサポートします。

すべてのコンポーネントを含める計画を​​必ず立てるようにしてください。その時点で完全なメリットが実現されます。

チームを連れて行きましょう。これが価値のあるものになるというコンセンサスがあることを確認してください。

于 2008-11-19T02:21:02.237 に答える