はじめに：
私たちの開発サイクルを単位としてスプリントに繰り返され、そして私達のそれぞれが私たちの結果が行う顧客をスプリントする方法なので、私はデモや新機能の数、またはいくつかのバグ修正をリリースする必要があります。デモはすべて次の会議を参照し、それを展開することで、一般的にはすべてのサーバー上で実行するために、私は、ここで議論していない、と私たちは、トピックに関するメジャーリリース（解放）を議論するためにここにいます。
実装：
トピック1：どのように我々は、出版社は、我々はこの機能をスプリント何をすべきか知っているのですか？JDKそれは大きなリリースだと小さなリリースは、彼らがこの機能を公開するかを説明するためにいくつかの論評を持っているか、我々は何をすべきか改正するたびに、のような、のように、私たちのアプローチがある、ので：
毎日の終わりにスプリント、およびプロジェクトへの変更（機能の変更/修正案）がある場合、プロジェクト内のリリースノートを追加します。
具体的なアプローチは次のとおりです。私たちは、Mavenのサイト・プラグインを使用し、その後、私たちはサイトフォルダを更新するたびに、中のsite.xmlへの「リリースノート」にエントリを追加します。
その後、我々はaptのファイルを追加し、どこプラスリリースノート
今、我々はあなたが我々がアップ書きこれらのリリースノートを表示することができ、MVNサイトを使用しています。
トピック2：合理的なリリース計画を選択します。
我々はアーティファクトを解放しようとしているときに、これは非常に難しい問題です。たぶん一部の人々はシンプルたい、それはそれで離れて取得していません構築、これは次のバージョンアップではない、と？あなたははるかに悪い行います。プロジェクトではなく、簡単な操作を公開したいので、あなたはその正しさを確認することを意味する、このプロジェクトのために非常に厳格な品質チェックを持っている必要がありますので、我々はいくつかの製品に配置する必要があり、回帰環境を行います回帰は問題ありませんならば、我々は回帰が、問題はない、いくつかの環境回帰するまで、私たちが安全にリリースを行くことができない環境のより高いレベルに行かなければならない。具体的には、私たちは、環境の4組の、すなわちのDevを持っていますDevInt、QA、生産、我々は層、何の問題を行かなければならない、我々は最終リリースとの両方の生産環境を公開することができます。そこで問題は、リリースコードリポジトリを移動するには、プロジェクトの開発者が同じ倉庫にコードを提出したときに解放リリースチームは、それが一貫性のないコードにつながる場合は、当社の開発は、反復時間であり、保持されているので、あります失敗を解放するためにつながります。私たちは今、厳密なコードフリーズシステムは、右のポイントリリース時間を選択する方法そして、このシステムは、ウォーターフォールモデルでは、ほとんどなので、私たちは開発を停止することはできません、ありませんか？このリリース計画では、解決すべき問題です。
この問題は、私は次のように具体的な構造は、予約なしで共有するために、ここで、合理的な解決策を考え出すために2日間かけて考え、私はリリース計画を設計するために招待された、非常に複雑です。
この図は、黄色のステータスバーは、開発チームを表し、緑色のステータスバーは、各スプリントでのテストチームを表し、才能は、Nは、N番目のスプリントを表し、N + 10、に私に10 N + 1となっています青の開発チームに代わってテキストアクションは、紫色のテストチームを代表してテキストアクションは、赤いテキストは、人間の行動の放出を示しています。
所 以从上图不难发现，对于开发团队来说，他们的主要开发日期是从(N+3)到(N+9)，一共7天，这七天他们做开发，所以会去碰代码仓库，而对于前2天 （N+1),(N+2)和最后一天（N+10)，他们都是做一些和代码无关的事情，所以不会去影响到代码仓库。所以我的建议是，让release的人在 Dev和DevInt上做release和Regression的时间控制在(N+1)和(N+2)，因为这两天代码仓库的稳定性是可以保证的，然后当开 发人员从N+3开始提交代码后，releaser做QA和Production环境的release和regression，这样不会影响开发团队提交代 码。
风险和经验分享：
其实最大的风险是对于开发团队，万一API或者UX Spec不是很明确，或者不稳定，这样他们的开发时间就会推迟，也许不一定从(N+3)开始了，对于这些情况，我的建议是，如果在(N+1)天遇到了这些 各种开发的不利因素，那么尽可能在(N+3)之前全部解决，如果能解决，那么最好，如果不能解决，那么scrum master可以砍掉一些story,这样至少可以保证开发团队的按时交付。
还有，就是万一release失败了怎么处理？我的建议是：如 果release或者regression失败了，那么代码会返回到开发团队的手里，然后变成一个urgent fix 的活动。如果开发团队足够给力，他们可以在N+1就解决了，那么万事大吉，如果到N+2才解决，那么开发团队就要推迟一天开发，从N+4到N+9,这就需 要他们适当提高效率，事实上我们在工作量预估时候也都加了很多buffer时间。如果到N+3了还没解决，那么releaser就停止release,并 且宣告N-1迭代的release 失败，然后等2星期再进行新一轮的release. 只有这样，才能保证整个流程的顺畅。
总结：
Release是一个非常重要的步骤，我们必须把好这一关。
（1）私たちはプロジェクトの進化を追跡するために、将来のノートを容易にするためのプラグインを使用し、十分な詳細で良好な剥離を追加することができ、プロセスのリリースを。
（2）非常に効果的なリリース計画は非常に重要である設計、重要な足場は、いずれかの役割の多様間のクロスではなく、互いにブロック、混乱を解放するプロジェクトの予定はありませんです。
この記事はから来て、「平行線結束」のブログ、http://supercharles888.blog.51cto.com/609344/1262090
ます。https：//www.cnblogs.com/JoannaQ/p/3251393.htmlで再現