タグ付けされた質問 「release」

私のプロジェクトで最初にコミットした結果、ナイトリービルドが壊れてしまい、リリースが近づいているので人々は私を取り囲んでいます。私は誠実に聞こえると同時に、これが私の最初のコミットであり、これがこれ以上繰り返されないことをほのめかす謝罪メールを送信したいと思います。 英語が母国語ではないので、正しい単語を見つけるのに苦労しています。誰か助けてくれますか？

181 continuous-integration  builds  release 

これは物流に関する質問であり、技術的な質問ではありません。 私の会社はいくつかの組み込みソフトウェアの仕事を外部委託しています。具体的には、社内で十分な知識を持っていないため、組み込みシステムを開発するために請負業者に支払いました（デスクトップアプリケーション開発者しかいない）。 そのため、請負業者はソフトウェアを完成させ、仮想マシンで提供するかどうかを尋ねました。VMは、ソースコードがCodeWarriorプロジェクトとして事前設定されたCodeWarrior IDEを含むWindows 8マシンです。これにより、このプロジェクトをさらに開発するためにすでに構成されているVM内でコードを変更できるようになります。 プロジェクトにコード変更を加えるために独自の開発マシンを構成する方法を説明してもらうのではなく、これを行うことには欠点がありますか？予見できる唯一の問題は、VMの実行が遅いことです。コードを変更すると、プロジェクトの再構築に時間がかかります。しかし、一方で、事前に構成された組み込みシステム開発環境を取得するというアイデアが好きなので、デスクトップアプリケーションの開発マシンに別のIDEを追加する必要はありません。 VMの成果物を受け入れない理由を考えることはできませんが、不足しているものがある場合に備えて、このコミュニティで実行したかっただけです。

40 virtual-machine  release  delivery 

assertC ++ のデフォルトの動作は、リリースビルドでは何もしないことです。これはパフォーマンス上の理由で、おそらくユーザーが厄介なエラーメッセージを表示しないようにするために行われたものと思われます。 ただし、assert不変式が壊れているためにアプリケーションがさらに悪い方法でクラッシュする可能性があるため、が発生したが無効になった状況はさらに面倒だと主張します。 さらに、パフォーマンスに関する議論は、それが測定可能な問題である場合にのみカウントされます。assert私のコードのほとんどは、より複雑ではありません assert(ptr != nullptr); ほとんどのコードにわずかな影響しか与えません。 これは私に質問を導きます：アサーション（特定の実装ではなく概念を意味する）はリリースビルドでアクティブにする必要がありますか？何故なの）？ この質問は、リリースビルドでアサートを有効にする方法ではないことに注意してください（#undef _NDEBUG自己定義のアサート実装を使用するなど）。さらに、サードパーティ/標準ライブラリコードでアサートを有効にすることではなく、私が制御するコードで有効にします。

20 c++  release  assertions 

ソフトウェア開発者の大企業がプログラムのバグをどのようにチェックするのかと思っていました。 彼らは複数のコンピューターでテストするだけですか？

15 testing  quality  release 

無料のライセンスでオーディオフィンガープリントソフトウェアプロジェクトをリリースしたいのですが、リポジトリには著作権で保護されたオーディオファイルが含まれています。現在、テストケースではこれらのファイルも使用しています。最大のバージョン履歴で、著作権を侵害せずにコードを公開するにはどうすればよいですか？ 詳細： コードはgitでバージョン管理されています。リリース前にすべてを1つのブランチに戻します。 400 MBのオーディオデータがあります。一部のファイルは、たとえばJamendoの無料ライセンス音楽であり、その他のファイルは私たちの個人コレクションのMP3です。 どのようなアプローチをとっても、プロジェクトの履歴を破壊しないように、常に元のリポジトリの不変のコピーを保持します。 主な質問：パブリックリリースの処理方法 問題のファイルのすべての履歴をgitリポジトリから消去し、変更されたリポジトリをリリースします。（v64 はこれを行う方法を指摘しました。） または、コードの現在の状態のスナップショットを取得し、プレリリースコードの公開履歴を気にすることさえしません。 副次的な質問：プロジェクトの初期段階でプライベートコードまたはメディアが必要になる場合があるので、そもそもこのジレンマをどのように回避できたでしょうか？

15 open-source  testing  git  release 

典型的な解決策は、ビルドサーバーで実行されているCI（継続的インテグレーション）ビルドを使用することです。これは、ソースコードの分析、ビルドの実行（デバッグ）、テストの実行、テストカバレッジの測定などを行います。 現在、通常知られている別のビルドタイプは「ナイトリービルド」です。コードドキュメントの作成、セットアップパッケージの作成、テスト環境への展開、テスト環境に対する自動（スモークまたは受け入れ）テストの実行などの遅い処理を行います。 さて、質問： リリースビルドとして3つ目の別個の「リリースビルド」を使用する方が良いですか？ または、リリースモードで「Nightly build」を行い、リリースとして使用しますか？ 会社で何を使用していますか？ （リリースビルドでは、潜在的な製品バージョンのソース管理に何らかのタグを追加する必要もあります。）

13 builds  release  continuous-integration 

ソフトウェアのすべてのバージョンの配信時に、リリースノートを作成する必要があります。たとえば、リリースノートを作成するときに追加する用語の一部を次に示します。 発売日 解決したバグ それで十分ですか、それとも何かありますか？

12 release 

最近、私はますます私はこの職業で私の最もイライラすると士気を殺す経験の一つとして記述する必要がありますどのように悩まされてきた：を有するリリースに座ってテストされている、再テストし、上演、およびすべての意図について目的は出荷/展開する準備ができています。 単なる筋金入りのコーダーではなく、万能のソリューションガイとして、適切な変更管理の必要性を理解し、提唱さえしています。しかし最近、私たちの拠点をカバーすることと時間通りに出荷することとの間の微妙なバランスがすべて崩れ、私はそれを健全なものに戻すことにほとんど成功していませんでした。 私は、リスク回避管理を説得するのに役立つ説得力のある議論を探しています： 開発チームは独自のリリーススケジュールを設定できる（またはする必要があります）-当然のことながら（1〜3か月は、Fortune 500の最大の企業を除くすべての企業にとって保守的なものです）。 ソフトウェアリリースは重要なマイルストーンであり、無頓着に扱うべきではありません。言い換えれば、不必要な遅延/停止は非常に破壊的であり、いくつかの重要なビジネス上の問題に対する最後の手段としてのみ考慮されるべきです。そして 関係者が関与することを望んでいる（または要求している）外部（非開発/非IT）エンティティは、特に計画された出荷前の1週間前など、リリーススケジュールを満たすために開発チームと協力する責任があります日付（つまり、ユーザーのテスト/ステージング）。 上記は経験に基づいて私に当てはまる主張ですが、私は今それを証明しなければならない立場にあるようです-そのようなものが存在する場合、私はここで少し肉の何かを求めています。 固定（または半柔軟な）リリースサイクルのアイデアを経営者に「販売」しなければならなかった人は、どの議論/戦略が効果的で説得力があり、何がそうでないかについていくつかの指針を与えることができますか？明らかなスケジュールの競合と埋没費用は別として、「企業」の設定であっても、出荷が実際に重要であると主張するのに役立つハードデータ/証拠はありますか？ 代わりに、スケジュールの柔軟性（週/月の期間であっても）がスケジュールどおりに出荷するよりも重要である理由について建設的な議論を聞くことができます。今私が信じるのは難しいが、彼らは私が知らないことを知っているかもしれない。 リリースを段階的に行っていることに注意してください。これは、実動を除くすべての段階を経て行われました。商用バグトラッカーを使用して問題を追跡し、このリリースに割り当てられたすべての問題（100％の問題）は終了しました。信じがたいことであり、それが本当に正確なポイントです-100％、機能が完全で、十分にテストされ、関係者によって承認されたリリースが、原因不明の理由で経営陣によって遅れることは意味がありませんが、それが起こったのは、それが何が起こっているのか、それが解決すべき問題です。

12 release  release-management  scheduling 

プログラムの作成者であるあなたは、おそらくセキュリティの脆弱性と潜在的なハッキングを知っている誰よりも優れた立場にいるでしょう。作成したシステムの脆弱性を知っている場合、リリース前にセキュリティを強化する兆候を追加する必要がありますか、それともケースごとに評価してセキュリティギャップの重大度を判断する必要がありますか？

12 security  release 

これらの 投稿は関連しているように見えますが、私の脳は溶け始めています：P 私の雇用主はソース管理の使用を開始しました。主に、彼らがより多くの開発者を雇う前に、「リポジトリ」は主に自宅で働く孤独な開発者のハードドライブだったからです。彼が書いた.NETコードはすべてまとめてチェックインされ、多くの重複した（読み取り：コピーアンドペースト）機能があります。現時点では、SCMシステムは栄光のバックアップです。 重複したコードの一部を共有ライブラリに引き込みたいです。元のリポジトリはそのままにしておき、何も壊さないようにします。必要に応じて既存のコードを移動および/またはリファクタリングできます。それで、ライブラリを含む新しいコードのためだけにリポジトリを設定しました。 私の問題は、過度のプロセスに悩まされることなくライブラリをバージョン管理することを中心にしています。ソリューションが生産性に影響を与え始めた場合、うまく落ちます。 私の強迫観念での理想的な解決策は、ライブラリを個別にビルドし、各依存プロジェクトを意図的に選択した互換性のあるバージョンに対してビルドすることです。そのようにして、どのクライアントがどのライブラリのどのバージョンを持っているか、バグをより確実に再現でき、製品とライブラリの独立したリリースブランチを維持でき、共有コードを変更するときに互いのプロジェクトを壊さないようにできます。 これにより、特に自宅で働く開発者にとっては、ライブラリの更新が面倒になります。少なくとも当初は（最終的に）共通部分をまとめると、ライブラリが急速に変化することを期待しています。私はこれを完全に考えすぎている可能性が高く、最新のライブラリコミットに対してすべてを構築するだけで構いませんが、少なくとも一部のコンポーネントを個別にバージョン管理する必要があると判断した日には備えたいと思います配布されました。一部のライブラリをGACにインストールする必要があるという事実により、バージョン管理は特に重要になります。 だから私の質問は：私は何が欠けているのですか？1つのソリューションに固執しているように感じますが、現在、変更をよりスムーズにするバリエーションを見つけようとしています。以前、この種の問題を解決するためにどのような戦略を使用しましたか？この質問はあちこちにあることを理解しています。不確実な点を整理し、明確にするために最善を尽くします。 そして、私はMercurialを使いたいと思っていますが、私たちはすでに集中型商用SCM（Vault）にお金を費やしており、切り替えはオプションではありません。また、ここでの問題は、バージョン管理ツールの選択よりも深くなると思います。

12 development-process  version-control  release  versioning 

私はCraig Larman著の 『Applying UML and Patterns』を読み始めたところです。それは私が仕事で言われたことの多くに挑戦するのでそれは非常に興味深いと思います。要件はアジャイルで一度に完全に収集されるわけではなく、要件の収集を完了するには多くの反復が必要であると私は読んだ。その場合、明日、新しい画期的な要件（または要件としてマスカレードする変更要求）が存在する可能性があることを考えると、ハードセットの締め切りを設定することになります。

10 agile  requirements  release  iterative-development 

リリースビルドを処理するようにJenkinsを設定する作業をしています。リリースビルドは、Linuxでビルドする必要があるいくつかのバイナリを含むWindowsインストーラーで構成されています。 ここに私がこれまで持っているものがあります： Windowsの部分とLinuxの部分は、別々のJenkinsプロジェクトとしてセットアップされます。 Windowsプロジェクトはパラメーター化されており、Subversionタグを使用してビルドおよびリリースされます。 ビルドの一部として、Windowsプロジェクトは（パラメーター化トリガープラグインを使用して）Linuxプロジェクトの同じSubversionタグのビルドをトリガーし、次に（アーティファクトのコピープラグインを使用して）LinuxプロジェクトからWindowsプロジェクトのワークスペースにアーティファクトをコピーします。 Windowsインストーラーに含めることができます。 行き詰まっているところ：現在、アーティファクトのコピーは、最後に成功したビルドをコピーするように設定されています。パラメーター化されたトリガーがトリガーした正確なビルドからコピーするようにアーティファクトのコピーを構成する方がより堅牢に見えますが、それを機能させる方法を理解するのに苦労しています。これを助けることを意図した「ビルドセレクター」パラメーターのオプションがありますが、それがどのように設定されることになっているのか理解できません（そして、ビルドに1時間かかると、さまざまな可能性を盲目的に試すのはやや苦痛です。成功または失敗を見つけるために1つまたは2つ）。 これはどのように設定すればよいですか？ビルドセレクターはどのように機能しますか？

9 release  jenkins 

いくつかの幼稚園から高校まで、一部の大学で使用されているオープンソースのPHP / MySQL Webアプリケーションを管理しています。私はプロジェクトの唯一の開発者でもあります。以前は、雇用主がホストするアプリケーションのソースダウンロードに過ぎませんでしたが、昨年、ドキュメント、番号付きリリース、公開変更ログなどを含む「本物の」オープンソースプロジェクトにするために取り組んできました。 アップグレードプロセスの改善を目指しています。特にITの専門家が不足している学校にとって、痛みを伴う可能性のある分野の1つは、リリース間でのデータベーススキーマの変更です。それらは頻繁に発生したり、大幅な変更になる傾向はありませんが、プロセスに関する提案をいただければ幸いです。 現在、データベースを新規インストールでセットアップするためのベースSQLインストールスクリプトを維持しています。これには、現在のリリースの完全なスキーマが含まれます。新規インストールの場合、これ以上のアクションは必要ありません。リリース間で発生する変更はupgrade-$releasever.sqlスクリプトに保存されます。スキップされたリリースについては、すべてのアップグレードスクリプトを段階的に実行する必要があります。 ユーザーの多くはシェルアクセスなしでホストを操作するため、シェルスクリプトは適していません。他の優先事項により、複雑なPHPブラウザーベースのインストーラー/アップグレードスクリプトが実現する可能性は低いです。ただし、アップグレードを簡素化するために、ブラウザーベースのPHPスクリプトを使用して何かを実行したいと思います。それへのアプローチ方法に関する提案？

9 database  release  upgrade  schema 

リリースごとに正確な変更ログを提供したいプロジェクトに取り組んでいますが、手間をかけずに機能する変更ログを収集する方法が見つかりませんでした。問題は主に、バージョン間の時間が長く、各バージョンに多くの機能とバグ修正が同梱されている場合、およびソフトウェアに複数のブランチが同時に開発されている場合です。 私が検討したいくつかのオプション： コミットメッセージから変更ログを作成し、開発者が変更ログの行を作成する場合と同じようにメッセージを書き込むように要求します（実際には変更ログを作成します）。 複数のブランチがあり、ブランチ間でマージする場合は機能しない可能性があります（どのコミットが最終的にリリースで終わったかを知るのは難しいかもしれません）。 コードの変更ごとに、バグ追跡システムに対応するチケットが必要であることを要求します。変更ログは、チケットに基づいて書き込むことができます。 開発者は、特にバグの修正よりもチケットの作成に時間がかかる場合は、マイナーな変更のチケットを作成するだけでもイライラするかもしれません。 開発者がコードに変更を加えると同時に、常に変更ログを（プロジェクトルートのテキストファイルとして）更新する必要があります。 自動化できる手作業のように感じます。 プロジェクトマネージャーに、現在のバージョンと以前のバージョンの差分を取り、変更されたことがわかったものに基づいて、その時点で変更ログを書き込むよう依頼します。 リリースの責任者のための余分な作業。コードを見ただけでは、変更の実際的な効果が何であるかは明らかではない場合があります。 リリース予定の機能のみを出荷してください。コーディングを始める前でも、変更ログを書き込むことができます。 ウォーターフォールモデルを使用していない限り、実際のオプションではありません。 私はこれらのそれぞれまたはそれらのバリエーションを過去に使用したことがありますが、それらはあまりにも信頼性が低く、面倒で、堅固でした。問題を解決する方法について魔法の弾丸または良いアイデアを持っている人はいますか？

8 version-control  release 

LPTHWを使用してプログラミングする方法を学び始めたばかりです。スキルレベルが上がったので、コードを出荷する準備ができているかどうかに関係なく、コードを出荷する習慣をつけて、常に出荷する習慣を身に付けたいと思います。配送コード。 出荷コードの初心者向けのガイドはありますか？

8 python  release  distribution  project-hosting