問題タブ [release-management]

次のコマンドのようなものを使用して、展開する tarball を作成したいと考えています。

内部の git diff コマンドは、個別に実行すると、相対パスを含む相対ファイルのリストを生成します。

ただし、出力でスペースを自動エスケープできるようにする必要があるため、tar はスペースを含むファイルについて文句を言わず、tar が作成されると、すべてのファイルに重複した「隠しファイル」があります。 「.」が前に付く ls -al では表示されません。これらは、kch で指摘されている OSX 固有のメタファイルです。

とにかく、これらの問題の解決策を知っている人はいますか、またはこれをスクリプト化する簡単な方法はありますか?

リリースの下でコンパイルして .pdb ファイルを展開する必要がありますか?

とにかくリリースビルドを行うときに、.pdb をコンパイルするのはなぜですか?

「Inspector.aspx」を使用して、デバッグ ビルドでいくつかのテストを実行しています。リリース ビルドでは (さらに重要なのは、インストーラーを作成するとき)、プロジェクトからページ (および関連する C# ファイル) を手動で除外します。

ASP.NET プロジェクトで選択したソリューション構成のファイルを自動的に除外する方法はありますか?

C++ プロジェクトでは、構成ごとにファイルごとに除外/包含を制御できます

私は製造会社のインハウス開発者として働いています。私たちは、実際には制御ソフトウェアではなく、プロセス フローのような製造プロセス用のソフトウェアを作成しています。

私たちはスクラムプロセスを使用してソフトウェアを開発していますが、チームと環境に合わせて調整されていますが、これは非常にうまく機能しています. 私たちはスプリントの終わりに近づいており、ソフトウェアは製品所有者が展開したい段階にあります。

以前は、つまりスクラムの前は、ソフトウェアを展開していました。ソフトウェアを開発し、ユーザーが定義した/合意したすべてのリリース テストに合格し、シミュレーターを使用して PO にソフトウェアをデモンストレーションし、目標を達成したと感じています。展開サポートを提供する準備はできていますが、展開するのは私たちの責任ではないと思います。

他の人々の経験とは？開発チームが展開を行うべきですか、それとも完成したソフトウェアを PO に引き渡してサポートを提供するだけですか?

まとめ

たくさんの素晴らしい反応、ありがとう。質問は、私が仕事や責任から身をよじろうとしているように見えるかもしれませんが、多分私は少しです ;o) 私がもっと興味を持っているのは、他の人々のプロセスです. ここで直面する問題は、開発チームがソフトウェアを展開すると、ソフトウェアの本番環境に 24 時間年中無休のサポートを提供することになります。私たちが2人しかいないことを除けば、問題ありません。そのため、常にサポートを提供するのではなく、ソフトウェアの開発に戻ることができるようにするために、開発プロセスに「IT」チームを関与させることが役立つのではないかと考えました。うまくいけば、これが「賛同」を得て、最初のレベルのサポートを展開して提供できるようになることを願っています。メキシコにも工場があり、開発チームがそこに行って展開するのは難しいため、現地のサポートがそれを行う方が理にかなっています。

念のために言っておきますが、IT エンジニアは開発者からのガイダンス/アドバイスを受けてソフトウェアを展開しました。これは非常にうまくいきました。顧客は満足しています。彼は自分のソフトウェアの価値を高めました。それがすべてではないでしょうか?

メジャー リリースでコードが出荷 (または展開) される前に、他のチームがどのような標準を整備しているのか、私は興味があります。

それぞれに対する特定の答えを探しているわけではありませんが、ここで私が理解しようとしていることのアイデアを示します。

• サーバーベースのアプリの場合、監視が実施されていることを確認していますか? どの程度... ping に応答するか、任意の時点ですべての依存関係をヒットできるか、アプリが実際にサービスを提供するロジックが適切であるか (たとえば、2+2 を計算するサービスが実際に「4 を返す」 "）
• コードをリリースする前に、自動化されたビルド スクリプトが必要ですか? つまり、開発者は誰でも新しいボックスに足を踏み入れ、ソース管理から何かをヤンクして開発を開始できますか? もちろん、OSやIDEなどを考えると。
• サーバーベースのアプリ用の自動展開スクリプトはどうですか?
• プロジェクトを「完了する」ためには、どのレベルのドキュメントが必要ですか?
• システムがサーバーベースの場合、システムのすべての主要コンポーネントに対して本格的なバックアップ計画を立てていますか?
• コードの品質基準を実施していますか? .NET または循環的複雑度評価の StyleCop を考えてみてください。
• 単体テスト？統合テスト？パフォーマンス負荷テスト?
• アプリケーションのエラー ログの処理方法に関する基準はありますか? エラー通知はどうですか？

繰り返しますが、必ずしも上記の何かに対する回答の行ごとのパンチリストを探しているわけではありません。要するに、コード リリースがチームにとって正式に「完了」したと見なされる前に、コード リリースが完了している必要がある非コーディング項目は何ですか?

いくつかのファイルをコピーし、exec タスクを介して makensis.exe を実行してインストーラー exe をビルドする nAnt スクリプトを使用して以前にビルドした NSIS インストーラーがあります。nant スクリプトが完了すると、CD とダウンロードの完全な構造が完成します。

ソースセーフから未使用のデスクトップに取得し、それをビルドボックスとして使用して、そこでコンパイルしていました。時には、いくつかのファイルをチェックインして、重要な問題を修正することもありました。そのような場合、私はビルド ボックスに移動し、それらのファイルのみを非常に選択的に取得して、まだリリースする準備が整っていない他の変更済みファイルを取得しないようにします。基本的に、私は開発を継続させ、特定の変更されたファイルを選択的にインストーラーに含めてリリースすることができます。

これで無料のボックスはなくなり、サーバーからビルドする必要があります。そのため、開発者がサーバーにリモート接続せずにビルドを開始できるように、CI Factory をセットアップしています。私が苦労している 1 つの問題は、この選択的な変更管理を引き続き行うための最善の方法です。CI Factory が実装する CI のデフォルトの概念は、社内開発の「頭」に適しています。ただし、この「公開リリース」タイプのビルドの強制ビルドを介してオンデマンドでのみ実行される CCNet プロジェクトもセットアップしたいと考えています。

これは私がこれまでブレインストーミングしたものですが、これがうまく機能するかどうかはわかりません (CCNet と CI Factory が何であるかはまだわかりません)。「パブリック リリース」CCNet プロジェクトの構成/ビルドは、最新のものにならないようにセットアップされます。変更は行われませんビルドをトリガーします。変更が検出されたときに最新のものを取得するデフォルトの CI 方法論 (「CI プロジェクト」と呼びます) を使用している他の CCNet プロジェクトでは、これら 2 つのプロジェクトは同じ作業ディレクトリを共有できません。したがって、「公開リリース」には別の作業コピーが必要になるため、CI プロジェクトのビルドがトリガーされたときにそのファイルが更新されません。開発者は、1 つの VSS であるサーバーにリモートでアクセスし、「パブリック リリース」の作業コピーに選択的にアクセスしてから、CI Factory を介して強制的にビルドする必要があります。

私がこれで見た欠点は、
1) 選択的に get を実行するためにリモートで接続する必要があることです。
2) 1 つの CI Factory プロジェクトが Product フォルダーの 2 つの異なる作業コピーを持つことを許可して、各プロジェクト構成ブロックが独自のものになるようにする方法がわかりません。
3) 私はこれがどのような奇妙さを引き起こすのではないかと心配している. CCNet プロジェクト構成ブロックでソース管理ブロックを指定する方法はまだよくわかりませんが、ビルド時に最新のものを取得しないようにします。私はまだ、スクリプトに何があり、他のものを壊すことなく簡単に取り出すことができるのか、いじられることを意図していないものや構成可能でないものとは対照的に、徐々に理解しています。

同様の状況があれば、他の人が変更を選択的にリリースするというこの問題にどのように対処しているかについて、本当に聞きたいです。私は VSS に制約されているので、それを念頭に置いてこれを解決することが当面の必要性ですが、同時に、他のソース管理システムでこれをどのように管理しているかを聞くことに興味があります。おそらく最新の開発ブランチであるブランチがあり、リリースしたいときはいつでも変更をトランクにマージすると思いますか? 私は分岐/マージに関して VSS を本当に信頼していません。分岐の概念は、このショップのオーバーヘッドと学習曲線が少し多すぎるのではないかと思います。私が言ったように、他のソース管理システムの話は、私にとって将来の有益な知識になるでしょう.

前もって感謝します。

同僚と私は、リリース/SCM システムでのタグの価値と使用法について議論しています。この問題を解決するために、StackOverflow コミュニティからの意見をお待ちしております。

一方では、タグはリリース管理にとって価値のある追加機能であると主張しています。それらの使用例: このリリースで使用されるコード スナップショットである新しいタグ (1.0 と呼びます) を作成する Maven リリースを行います。このタグは READONLY ブランチである必要があります。バグを修正する必要がある場合、タグのコピーを新しいブランチ (1.1 と呼びます) に作成できます。バグ修正はそこに行きます。これらの修正は、メインの開発ブランチがバグ修正を取得できるように、トランクに再びマージされる場合があります。最後に、1.1 がリリースされ、タグ 1.1 が自動的に作成されます。このサイクルは続きます。ここでの Tag の主な利点は、何らかの理由でバージョン 1.0 を再リリースする必要がある場合に、誰も変更されていないという確信を持って Tag 1.0 をリリースできることです。また、「Release Tag 1.0」と言う方が、「元の 1 であるブランチ 1.0 のリビジョン 1 をリリースする」よりも簡潔です。

反対側は、特に CVS のタグのように機能するグローバル リビジョンを備えた Subversion のようなシステムでは、タグは価値のある利点を提供していないと主張しています。さらに、Subversion はタグにコミットするときにのみ警告を出します。それは実際にそれを止めません。彼らの方法はトランクで開発されており、リリース時に 1.0 というブランチを作成します。Trunk で引き続きバグ修正を行い、それらのバグ修正を本番環境に再リリースする必要がある場合は、それらを 1.0 Branch にマージして 1.0 を再リリースします。ある時点で、おそらく Trunk の主要な修正または機能の後、Branch 1.1 をリリースして作成します。サイクルは続きます。元の 1.0 バージョンをリリースする必要がある場合は、Branch 1.0 リビジョン 1 をチェックアウトする必要があります。

明らかに、両方の方法が機能します。どちらの方法が好まれているか、またその理由について、コミュニティの意見を聞きたいです。

編集:「最善の」方法が基礎となる SCM システムに依存することを少し心配しています。Subversion で解決するか、可能であれば SCM にとらわれないようにしてください。

バッチタスク プラグインを使用して内部リポジトリに Maven リリースを行うように Hudson をセットアップしています。私はそれをやっています：

人々が使用した他の方法と、それらの方法の長所と短所に興味があります。また、人々が遭遇した落とし穴。

当社では新製品の最初のリリースが近づいています。さまざまなコンポーネントすべてのバージョンを管理し、それらのコンポーネントを当社のソフトウェアのマーケティング部門のバージョンと相互参照する最善の方法を決定しようとしています。さまざまな理由から、当社の製品の最初のリリースは 10.1 であることがマーケティングによって決定されましたが、すべてのコンポーネントは最初は 1.0.0 から開始されます。通常のバグ修正、パッチ適用、継続的な開発作業により、異なるコンポーネントは同じバージョン番号ではなくなるため、マーケティング部門がバージョン 10.2 の時期であると判断した場合、1.1.54、1.2.32、1.8.2、もちろん、単純なスプレッドシートを使用することもできますが、それは最もユーザー フレンドリーな方法とは言えません。

これにはより「専門的な」方法がありますか、それとも単純なスプレッドシートが最適なオプションですか?

既存の基幹業務アプリケーションの拡張に取り組んでいる場合、変更を頻度の低い大きなリリースにまとめるのが良いと思いますか、それとも小さなリリースで新しい機能を継続的に出荷するのが良いと思いますか？ハードウェアのアップグレードまたはデータベースのアップグレードがあると仮定して、これらの変更をリリースでも行いますか、それとも別々に保ちますか？

すべてを一緒にリリースすると、ビジネスの中断が少なくなり、時間外の作業が少なくなるという利点がありますが、後で発生する問題は、データベースのアップグレード、ハードウェア、またはソフトウェアの変更が原因である可能性があります。

リリースはほとんどなく、多くの場合、リリースに起因する問題の追跡が容易になりますが、より多くの混乱と回帰テストに費やされる時間が発生します。

どちらが良いですか？