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

これは実際には技術的な質問ではありませんが、ソース管理とベストプラクティスに関する他の質問がいくつかあります。 私が働いている会社（匿名のまま）は、ネットワーク共有を使用してソースコードとリリースされたコードをホストしています。開発者または管理者は、ソースコードがリリースされているか、どのバージョンであるかなどに応じて、ソースコードを適切なフォルダーに手動で移動する責任があります。ファイル名とバージョン、および変更内容を記録する場所の周りにさまざまなスプレッドシートが点在しており、一部のチームは各ファイルの先頭に異なるバージョンの詳細も記載しています。各チーム（2〜3チーム）は、社内でこれを異なる方法で行うようです。あなたが想像できるように、それは組織化された混乱です-「正しい人々」は彼らの物がどこにあるかを知っているので組織化されていますが、それはすべて異なっていて、それはいつでも何をすべきかを覚えている人々に依存しているため混乱です。 私はしばらくの間、ある種の管理されたソース管理を推進し​​ようとしてきましたが、社内で十分なサポートを得ることができないようです。私の主な議論は次のとおりです。 私たちは現在脆弱です。いつでも誰かが私たちがしなければならない多くのリリースアクションの1つを行うのを忘れることができます。これは、バージョン全体が正しく保存されないことを意味します。必要に応じて、バージョンをつなぎ合わせるのに数時間または数日かかる場合があります バグ修正と一緒に新機能を開発しており、一部の作業がまだ完了していないため、多くの場合、どちらか一方のリリースを遅らせる必要があります。また、バグ修正だけが必要な場合でも、新しい機能を含むバージョンを使用するようにお客様に強制する必要があります。 複数の開発者が同じプロジェクトを同時に使用しているため、Visual Studioで問題が発生しています（同じファイルではありませんが、依然として問題が発生しています） 開発者は15人しかいませんが、私たちはすべて異なる方法で作業を行っています。私たち全員が従わなければならない標準的な全社的なアプローチをとる方が良いと思いませんか？ 私の質問は： このサイズのグループにソース管理がないのは正常ですか？ 私はこれまで、ソースコントロールを持っていないための唯一の漠然とした理由が与えられている-あなたが示唆している何の理由の可能性のために有効ではない 上記の情報与えられ、ソースコントロールを実装しますか？ 任意のより多くの理由があるため、私は私の兵器庫に追加できるソースコントロールは？ 私は主に私がなぜそんなに抵抗したのか感じてもらいたいので、正直に答えてください。 私は、最もバランスのとれたアプローチを取り、3つの質問すべてに答えたと思う人に答えます。 前もって感謝します

152 version-control  project-management  management  release-management 

リリース日が技術的なものに基づいて設定されているのではなく、営業担当者がそれまでに顧客にコミットしているため、繰り返し立ち往生しているようです。他の会社で開発中の友人との議論に基づいて、同じことが起こるようです。 「ここがコミットされた機能セットであり、ここがコミットされたリリース日です」と主張するのは困難です。なぜなら、この時点でそれに乗っているお金があり、それがすべてに勝るからです。 一般的に、これを後押しする方法はありますか？ このリリースではない場合、将来的にはどうですか？私が抱えている問題は、私がそうする一つの方法を見る唯一の方法であり、それはできる限り最善を尽くすことですが、いわば「現状のまま」ソフトウェアをリリースすることです。 私の名前が付けられているので、バグの多いソフトウェアをリリースしたくありませんが、一度に数か月間80時間週を実行するだけで、任意に設定されたリリース日を証明するだけです。 編集：記録のために、私は今80時間の週をやっていない、ちょうどそれはリリース日までに予想される機能セットをカバーするために必要なものとして思い浮かぶ。

120 communication  estimation  release-management 

私は最近、自分のコードをバージョン管理下に置き始めました（私が働いているラボではSVNで、自分のコードはgithubで（明らかにgitで））。バージョン管理を使用する前に、私はこのようなことをしていました。バージョン番号の付いた多くのフォルダーの中に、ライブラリーの名前のフォルダーがありました。新しいバージョンで作業を開始するたびに、最後のバージョンのコピーを作成し、名前を新しいバージョンに変更して実装を開始します。 ただし、フォルダがバージョン管理下に置かれている場合、これはかなり冗長に思えます。冗長性は別として、誰かが最新バージョンを入手したい場合、彼import/ 彼女たちがちょうどあればすべてのバージョンをダウンロードするでしょうclone。 現在、バージョン管理を使用してこれを行う多くの方法を見ていますが、私はそれが初めてなので、どちらがより保守可能かはわかりません。 方法1：タグを使用する 私がタグを正しく理解していれば、メインブランチがあります。取得した変更をコミットし、バージョンでタグ付けします。次に、作業コピーを取得したい場合は、特定のタグが付いたコピーを取得します。（間違っている場合は修正してください） 方法2：分岐バージョン この方法では、メインブランチは開発ブランチになります。時々、安定したバージョンがv1.2.0作成されるとしましょう（たとえば）、そのバージョンのブランチを作成し、コミットしません。そうすれば、特定のバージョンをダウンロードする場合、そのブランチからコードを取得できます。私はあなたがそれにコミットすることは決してないと言ったが、バグ修正を行い、古いバージョンのブランチにコミットして古いバージョンを実行し続けることが可能かもしれない。現在のバージョンがある場合たとえばv2.0、しかし、使用したい人がいるv1.2、あなたはから別のブランチを取得することができv1.2、すなわち、v1.2.1およびバグ修正をコミット、またはちょうど同じバージョンを保持v1.2し、単にバグ修正をコミットします。 したがって、ブランチは次のようになります。 v1.2.1 v1.2.2 / / v1.0.0 v1.2.0--------- v2.0.0 / / / -------------------------------------- dev このようにして、マイナーバージョンアップデートごとにブランチを作成できます。（上のグラフでは、v1.2.1とv1.2.2、またはv2.0.0のリリース後に作成されたため、v1.2.0とv2.0.0の間の開発の一部ではないことに注意してください。古いバージョンのサポートと考えてください） 方法3：分岐開発 この方法は前の方法の反対です。メインブランチは最新の安定バージョンです。新しいバージョンで作業しているときは常に、（開発用の）ブランチを作成し、コードで作業し、安定しているときにメインブランチとマージします。 この場合、ブランチは次のようになります。 ________ ____ ________________ _____ dev / \/ \/ \/ ---------------------------------- latest_version おそらくこれはタグと組み合わせて行う必要がありますか？ 質問！ とにかく、私の質問はあなたの経験に基づいて、これらの方法のどれがより実用的であると証明しますか？そこに知られている最良の方法はありますか（おそらく私は自分自身を理解していなかった）？これらのことは一般的にどのように行われますか？

24 version-control  git  svn  branching  release-management 

などの製品バージョンは、v1.0.0.100ソフトウェアの固有の製品リリースを表すだけでなく、その製品の機能セットと修正プログラムの段階を識別するのに役立ちます。現在、製品の最終パッケージ/ビルド/バイナリバージョンを維持するための2つの方法があります。 バージョン管理。ファイルはどこかにバージョン番号を保存します。Continuous Integration（CI）ビルドサーバーには、このチェックインバージョン番号を使用して必要なソフトウェアのすべての領域（バイナリ、インストーラーパッケージ、ヘルプページ、ドキュメントなど）に適用するソフトウェアをビルドするスクリプトがあります。 環境および/またはビルドパラメータ。これらはバージョン管理外で維持されます（つまり、スナップショット/タグ/ブランチに関連付けられていません）。ビルドスクリプトは、同じ方法で番号を配布および使用しますが、値の取得方法が異なります（ソースツリーに対する相対位置をスクリプトに知らせるのではなく、ビルドスクリプトに提供されます）。 最初のアプローチの問題は、メインラインのブランチ間でマージが複雑になる可能性があることです。同じソフトウェアの2つの並行リリースを引き続き維持する場合、最後のマージ以降に両方のバージョンが変更されている場合、2つのメインライン間のマージ時に競合を解決します。 2番目のアプローチの問題は、調整です。1年前のリリースに戻ると、タグ情報のみに依存してリリース番号を識別します。 どちらの場合も、CIビルドの前に知られていないバージョン番号の特定の側面があるかもしれません。たとえば、CIビルドは、実際には自動化されたビルド番号である4番目のコンポーネント（たとえば、ブランチ上の140番目のビルド）にプログラムで配置できます。VCSのリビジョン番号でもあります。 ソフトウェアのバージョン番号を把握する最善の方法は何ですか？VCSで「既知の」部品を常に維持する必要がありますか？もしそうなら、メインラインのブランチ間の競合は問題ですか？ 現在、CIビルドプラン（Atlassian Bamboo）で指定および維持されているパラメーターを介してバージョン番号を維持しています。masterブランチにマージする前に、CIビルドの開始前にバージョン番号が適切に設定されていることを注意する必要があります。Gitflowのワークフローに関しては、ソース管理でバージョン番号が追跡されていればrelease、リリースの準備でブランチを作成するときに、バージョン番号が適切に設定されることを保証できると思います。QAは、このブランチで最終的な統合/スモーク/回帰テストを実行し、サインオフ時に、masterリリースへのコミットメントを示すマージが行われます。

22 version-control  continuous-integration  versioning  release-management  continuous-delivery 

これは非常に基本的な質問です。誰かが私にユーモアを与え、彼らがこれをどのように処理するかを教えてくれたら、私はとてもうれしいです。 SynchToyをインストールして以下の問題を修正しようとしているため、これを投稿することにしました。 この状況にいると、何度も痛みを伴う明白な方法を見逃しています。これは、会社で唯一の開発者であることに起因しています。 職場のコンピューターで開発されたASP.NET Webアプリケーション ソリューションには2つのプロジェクトがあります。 ウェブサイト（ファイル） WebsiteLib（C＃/ dll） Gitリポジトリを使用する GoGrid 2008R2 Webサーバーに展開 展開： コードを変更します。 Gitにプッシュします。 サーバーへのリモートデスクトップ。 Gitからプルします。 Windowsエクスプローラーでドラッグ/ドロップして、ライブファイルを上書きします。 ステップ5では、Webサイトのルートからすべてのファイルを削除します。これは良いことではありません。だから、SynchToyをインストールしようとしています... 更新：すべての有用な応答に感謝します。答えをマークするものを選択することはできません-Web展開を使用する間に-いくつかの有用な提案があるように見えます： Webプロジェクト=単一のDLLにパッケージ化されたサイト全体-単純な更新をプッシュすることはできません-50人の会社の孤独な開発者であるため、これは時々より単純なもののままです。 SCMからサイトのWebルートに直接移動します-私はもともと、SCMの隠しディレクトリが公開されることを恐れてこれをしませんでしたが、ここでの回答はそれを乗り越えるのに役立ちました（私はまだ1確認するのを忘れることを心配することは、時間の経過とともにまだ真実です） Webファームを使用し、ノードに体系的に展開する-これは、ダウンタイムがゼロの理想的なソリューションです。これは、サイトが本質的に会社のリアルタイムの収益源であるため、実際に私が気にしていることです。ただし、サーバーのコストは2倍になります。 ->最後に、サイトのシングルクリック展開が必要であるか、または他に何か間違っている必要があるという基本原則の強化は、おそらく私が答えから得た最も有用なものです。 更新2：私はこれに戻って、今何ヶ月もの間存在し、完全に機能している実際のソリューションで更新すると思った（私の単一のWebサーバーソリューション）。 私が使用するプロセスは次のとおりです。 コードを変更する Gitにプッシュ サーバーへのリモートデスクトップ Gitからプル 次のバッチスクリプトを実行します。 cd C：\ Users \ Administrator ％systemroot％\ system32 \ inetsrv \ appcmd.exe停止サイト "/site.name:Default Web Site" robocopy Documents \ code …

21 web-development  deployment  websites  release-management  configuration-management 

テスターに​​サインオフ権限を与えることは理にかなっていますか？テストチームが 機能、問題などをテストし、合格/不合格ベースで報告するだけで、それらの結果に基づいて行動することができます。 それらの結果に基づいて、リリース自体を保持する権限がありますか？ つまり、テスターは実際にリリースを承認する必要がありますか？私が取り組んでいるテストチームは、彼らがそうしていると感じており、「スコープクリープのテスト」が原因でこれに問題があります。

20 testing  release-management  process 

私は現在、多くのパブリックな用途があるライブラリを管理しており、セマンティックバージョン管理について質問がありました。正しく実装されていないライブラリのかなり重要な部分をリファクタリングしたい-そして常に正しく実装されていない。ただし、これを行うと、パブリックAPIが変更されることになり、これは大きな決断です。 私が行いたい変更は、イテレータの使用方法を中心に展開します。現在、ユーザーはこれを行う必要があります。 while ($element = $iterator->next()) { // ... } 少なくともPHPのネイティブIteratorインターフェイスでは、これは正しくありません。これに置き換えたい： while ($iterator->valid()) { $element = $iterator->current(); // ... $iterator->next(); } これは次のようなものです： foreach ($iterator as $element) { // ... } トムのセマンティックバージョニングのガイドを見ると、パブリックAPIへの変更（つまり、下位互換性のないもの）はメジャーリリースを正当化すべきであると明確に述べています。したがって、ライブラリは1.7.3から2.0.0にジャンプしますが、これは私にとってはあまりにも大きな一歩です。修正される機能は1つだけです。 最終的に2.0.0をリリースする計画はありますが、ライブラリを完全に書き直し、多数のパブリックAPIの変更を実装したときだと思いました。このリファクタリングの導入は、メジャーバージョンリリースを保証しますか？私は本当にそれがどのように見えるかわかりません-私は1.8.0または1.7.4としてそれをリリースすることをより快適に感じます。誰かアドバイスがありますか？

18 versioning  release-management  semantic-versioning 

リリースの締め切りは明日です。同僚はこのリリースに不可欠なタスクをやっと完了しました。プロジェクトマネージャーは肩越しに立ち向かい、最終的にビルドを作成するように促しました。重大なものではありませんが、明日リリースされなければ、手放せないものです。そして、事態を悪化させるには、できるだけ早く終了するために必要な自分の仕事があります。それで、あなたは何をしますか？プレッシャーにも関わらず異議を申し立てますか、それともこれを滑らせますか？ 私が見つけた1つの方法は、このコミットを別のブランチに一時的にマージし、後で確認できるようにすることです。問題が表面的なものであり、コードレビューを待っている唯一の問題である場合に機能します。しかし、これを処理するより効率的な方法はありますか？たとえば、コードレビューとテストのみを1人で行うことをお勧めしますか？

17 version-control  code-reviews  release-management 

私は、他の人が次の問題を解決した効果的な方法を集めようとしています。職場では、特定のお客様にのみ表示したいソフトウェアパッチ（エンドユーザーシステムにインストールする）のリリースを余儀なくされています。カスタムコードは、独自のソース管理ブランチにあります。問題は、同期を保つために2つの並列コード行（およびビルドスクリプト）があり、元のコードにパッチを適用するたびに、顧客固有のコードにパッチを適用してテストする必要があることです。 他の組織はこのシナリオをどのように処理しますか？技術的な（ソース管理に関連する）ソリューションだけでなく、ビジネスソリューションにもオープンです。たとえば、そのブランチで更新を受信できないことを顧客に伝えることについて話してきました。 分岐戦略は次のようになります（Visual Studio TFS Branching Guideに基づいていますが、Subversionを使用しています）

16 version-control  business  release-management 

ここに少しの背景があります-私たちは、大規模な非ソフトウェア会社の内部ソフトウェア開発を担当するRAD開発者の小さなチーム（5人）です。「内部ソフトウェア」は、MSSQLサーバーをバックエンドとして使用するデスクトップ.N​​ETアプリケーションと、バックグラウンドで実行されるPythonスクリプトからMS Word文書やテンプレートに至るまでさまざまです-技術の動物園。 チーム全体は、ユーザーから要件を取得し、コードを作成し、テストし、運用環境に展開できるすべてのアロンダで構成されています。本番環境のソフトウェアは、別のチームによって管理されていますが、通常、何か問題が発生した場合は簡単に介入できます。 これまでのところはすべて良さそうですが、問題があります-RADチームであるため、頻繁にリリースする必要があり、1つまたは2つのアプリケーションの新しいバージョンをリリースせずに1日を過ごすことはできません（または、スクリプト、更新されたWordドキュメント、C ++コンソールアプリなど）を本番環境に追加します。開発テストを行い、エンドユーザーがUAT環境でソフトウェアを実行できるようにすることで、エンドユーザーも関与させます... ...しかし、バグはとにかく生産に忍び込んでいます。ユーザーはこれらのバグと時折の不安定性が本当に欲しいものをすぐに手に入れるために支払う価格であることを理解していますが、同時に考えさせられました-おそらく開発やリリースのプラクティスを改善して安定性を改善できるかもしれません新しい機能を追加するときに導入するバグの数を減らします。 良いこと-そもそもプロセスがあまりないので、改善を開始しやすいはずです。悪いこと-実装する時間とリソースがあまりない小さなRADチームであること大きなことですが、次のイニシアチブについて検討しており、フィードバック、ヒント、ヒント、提案を歓迎します。 現在、一部のアプリケーションは、ユーザー受け入れテストをバイパスして、開発者テストの直後に本番環境にリリースされています。その慣行は中止されるべきであり、小さな変更でさえエンドユーザーがテストする必要があります。各アプリケーションには、エンドユーザーから選択された専用のベータテスターがあります。ベータテスターが新しいリリースを承認した場合のみ、テストから実稼働環境に昇格されます。 コードレビューは実施しませんが、変更セットをチェックインする前にコードレビューを開始します。また、「ロールアウトレビュー」についても考えていました。基本的に、開発者の1人がソフトウェアロールアウト（バイナリのコピー、設定の更新、データベースへの新しいテーブルの追加など）を行う他のウォッチと一緒に隣に座っている必要があります-通常は5〜10分かかるため、「ロールアウトレビュー」の時間はあまりかかりません。 新しいリリースが、本番環境から撤退し、適切な以前のバージョンに置き換えられるほどバグが多いことが証明されている場合に、ロールバック時間を短縮する方法。すべてのリリースの履歴を（バイナリとして）保存して、1つのバージョンに簡単に戻せるようにします。また、「新しくリリースされたバイナリを以前のバージョンのバイナリで上書きする」のは簡単ですが、エラーが発生しやすい手動プロセスです。また、「ロールバックが失敗し、システムがバグの代わりに使用不能になる場合はどうするか」を時々要求します。 ここでアイデアを使い果たしました。これらについてのフィードバックを受け取りたいと思います。簡単なリリース/開発プロセスの改善アドバイスを共有できれば、それは素晴らしいことです。

15 development-process  release-management  rad 

リリースされたバイナリをバージョン管理下に保つにはどうすればよいですか？これにより、各リリース間で変更された内容を追跡できます。ソースリポジトリからリリースされたバイナリを分離するつもりです。リリースされたバイナリは、継続的インテグレーションソフトウェアから構築されるか、手動でコンパイルされます。

14 version-control  release-management 

幅広い質問であることは承知しておりますので、できるだけ具体的にお話しさせていただきます。この質問は、技術的な質問よりも「組織的な」質問です。 これらの主なコンポーネントを持つマルチサイドプロジェクトがあります。 コアビジネスロジック（データモデル）をホストするサーバー コアビジネスロジックを使用するクライアントのバックオフィス コアビジネスロジックも使用するアプリケーションAPI（REST） アプリケーションAPIを使用するスマートフォンアプリ（iOSおよびAndroid）があります。 スマートフォンとは別のタブレットアプリ（android）があり、同じアプリAPIを使用しています。 すぐに、私はアクティブなクライアントで生産されます。そして、どんなプロジェクトでも、私はすべての異なるコンポーネントを長期にわたって維持する必要があります。つまり、以下のすべてをアップグレードできます。 サーバーのコアビジネスロジックのコード（バックオフィス、API、および副作用としてモバイルアプリで使用） API自体（スマートフォンアプリとタブレットアプリの両方で使用） すべてのモバイルアプリ（appstore / googleplay経由） もちろん、サーバー側の部分（コアビジネスロジックコードとAPIコード）は自分ですぐに変更できます。ただし、新しいモバイルアプリはappstore / googleplayでクライアントがダウンロードする必要があり、それらが最新であるかどうかはわかりません。 これらのアップグレードをスムーズに行い、クライアントにリスクを与えないようにするためのガイダンス、優れた実践のヒントを教えてください。 どのバージョンの「バージョン」を作成する必要がありますか？クライアントがモバイルアプリをアップグレードしなくても、すべてが確実に機能するようにするにはどうすればよいですか？私に仕事を楽にするために彼にアップグレードを強いるべきですか？ つまり、マルチサイドプロジェクトを長期にわたってライブにするには、どのように整理すればよいですか？

14 design  architecture  project-management  deployment  release-management 

私たちは、独自のgitリポジトリを管理する複数のチームを持つ小規模企業です。これはWebプラットフォームであり、各チームの成果物は夜間テストのために1日の終わりに展開されます。バージョン管理とパッケージングに関するプロセスを形式化しようとしています。 すべてのチームには、日々の開発を行うマスターブランチがあります。各チームの品質保証メンバーは、チームの変更による成果物を、すべてのコンポーネントがシェフによって結合されるテストベッドに展開することを望んでいます。アーティファクトはtarballですが、それらをRPMに変換して、バージョンについて正しく考え、推論できるようにします。 リリースプロセスには、各gitリポジトリの開発ブランチ（ほとんどの場合マスター）からリリースブランチを切り離すことが含まれます。これは、成果物のセットでテストとサインオフを実行する品質保証に与えられます。 たとえば、これは関連するリリースブランチを持つ典型的なgitリポジトリです。 0-0-0-0-0-0-0-0-0-0 (master) | | 0 0 (rel-1) | 0 (rel-2) 開発ブランチから来るパッケージのバージョン管理を実行するスキームを見つけようとして立ち往生しています。各リポジトリのmasterブランチに過度にタグを付けたり、タグをリリースブランチのみに制限したりするのは望ましくありません。ただし、標準のyum / rpmセマンティクスを使用して、テストマシンにデプロイされたパッケージを照会できる必要があります。masterブランチにタグがない場合、開発バージョンはどのようになりますか？私git describeはビルドバージョンの有用な表現を提供できることを理解していますが、ブランチ上のさまざまなリリースポイントがタグ付けされている場合はうまく機能します。 EDIT1：@ Urban48の回答に応えて リリースプロセスについてもう少し説明する必要があると考えました。この議論のためにmaster、すべてのリポジトリにブランチがあると仮定しましょう。このmasterブランチは開発ブランチと見なされ、CI-CD対応の自動化されたQA環境に展開されます。これは、マスターの安定性を確保するために夜間テストのサブセットが実行される場所です。リリースブランチをカットする前に、このジョブのパイプラインを確認します。リリースブランチは短命です。リリースブランチを（安定したマスターから）カットした後、完全なリグレッションが実行され、修正が行われ、運用環境に展開されたとします。これには約1週間かかります。ほぼ2週間ごとに実稼働環境にリリースします。 機能ブランチは常にマスターから切り離され、CI-CD安定性チェックを受けるマスターとマージする前に、ある程度の開発者テストを受けます。 修正プログラムは（リリースブランチからカットされた）修正プログラムブランチで作成され、本番環境への影響を最小限に抑えて展開されます。 リリースおよびホットフィックスブランチのバージョン管理戦略は、semverに従います。QAサイクル中のリリースブランチはv2.0.0-rc1、v2.0.0-rc2などのバージョンを通過し、最終的にQAサインオフがになりv2.0.0ます。 バージョンがになるリリースブランチ（およびマスター）にマージされる小さな機能のドットリリースを行うことがありますv2.1.0。また、ホットフィックスはv2.1.1パターンを想定しています。 ただし、問題はこれらのブランチをバージョン管理することではありません。このバージョン管理スキームをまったく変更しないことをお勧めします。唯一の変更点は、開発ブランチ、つまり 主人。CI-CD環境で、以前のリリースから実稼働環境に存在するバージョンを確実に示す方法を教えてください。これは、理想的にはスマートgitタグ付けによって行われますが、masterブランチに過度にタグ付けしないものが推奨されます。

13 git  continuous-integration  versioning  release-management  packages 

だから私は2011年から2012年までずっと取り組んでいるプログラムを持っていますが、最後のリリースは2011年 12月でした。私は積極的に取り組んでいますが、機能クリープはそのい頭を誘い、今では未完成の機能に関する大量の情報で満たされています。 悪い点は、機能を実装するときに新しい機能が忍び寄るということです。将来、機能のクリープを回避して、1年以上で実際にリリースできるようにするにはどうすればよいですか。 このプロジェクトはiOSに基づいており、以前は各iOSバージョンの更新に関するリリースがありましたが、最後のリリースは5.1（2011）で戻ってきました。安定したリリースサイクルを取り戻せるようにしたいのですが、難しすぎることがわかりました。

12 programming-practices  release-management  scope-creep 

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

12 release  release-management  scheduling