发行产品是任何软件公司工作中最重要的部分。 但是，如果您害怕发布，则可能是您做错了什么。 我将告诉您通常如何组织发行。 本文并不打算作为详尽的指南，因为在软件开发行业中，所有事情都是独立的。
如何准备发布？
选择负责人
您可以轮流值班，掷骰子或拉火柴-任何方式都不错。 重要的是人员的轮换和对不知道如何释放人员的培训。 例如，掷骰子时，您可以输入以下规则：上次值班的人有权转移，如果他连续两次值班，那么您自动不值班。 不应将责任当作惩罚或征兵，必须有可以保证的人。
自定义日历
在公司日历中设置日期，并确保所有利益相关者都知道。
在Wiki上制作表格
指明表格版本，发布日期和负责人。 这对于维护历史数据更为必要。 您可以并且应该立即注意发布是否成功以及发布中包含的内容。
发行说明
这就是“版本中确切包含的内容”。 首先，这些数据需要与分析人员共享：他们可以将KPI中的任何更改与该版本中包含的内容进行比较。 基于这些数据，他们可以得出有关用户需要什么功能，哪些想法好而哪些想法不好以及下一次迭代将要做什么的结论。
内部公告
对于其他部门来说，重要的是要知道发布的时间，例如，在社会服务中发布职位。 有关产品新版本的网络（创建信息指南），监控KPI（指标可能会上升或下降）等。
发布期间
创建发布早午餐
除了修复严重的错误外，不应更改要发布的代码。 在理想情况下，任何修复都应通过池请求。 另外，所有测试都应为绿色。
发送通知
您需要通过邮件或在Messenger中通知所有人，已经创建了发布早午餐，并且正在准备发布。
制作标签
一定要在发布完成后制作一个标签，然后将这些修订拧紧到开发分支中。
自行发布
理想情况下，您应该具有控制发布的机制：例如，仅发布10％的用户或仅释放非付款人。 为此，这是必要的。 减少开发过程中发生的错误以及测试期间未发现的错误所造成的损害。
一键释放
神话般。 当然，释放所涉及的人为因素越少越好。 但这是正常的，如果不是所有的东西都可以自动化的话。
如果一切按计划出错
当然，万一发生任何错误，您不能互相指责，但您需要共同解决问题，并提出计划以防止将来发生此类事件。
释放后
监控
不要忘记监视错误，服务器负载。 还值得关注KPI：如果发布了版本，但DAU下降了，则可能是某些工具无法正常运行，或者监视工具本身已损坏。 任何可疑的活动都值得检查。
报告成功和失败
如果他们从开发人员那里而不是从用户那里了解问题，那就更好了。 当然，如果您解决了任何问题，那么可以放心地夸耀它。
回顾性
当然，这在某种程度上取决于开发方法，但是如果在发布过程中出现问题，则值得讨论。 如果事情很好，那么也值得讨论。 理想情况下，在董事会上每个失败点应该是对同事的成功或感激之情。 这将有助于避免使回顾陷入into和负面。
订购比萨饼并庆祝
在这样的聚会中，只有同事成为朋友和同志。 这意味着在下一场战斗中，朋友们不会让你失望的。
开始准备下一个版本
当每个发布定期在明确定义的日期进行时，我非常喜欢发布培训的想法。 因此，发布机制已由团队调试。 就像我在上面写的，没有必要向100％的用户发布：可以将其发布给一小群人。
其他公司如何发布？
Spotify
Spotify通常会根据Release训练的实践进行发布。 就像这种做法的名称所暗示的那样，该版本与火车非常相似：那些没有时间完成工作的人正在等待下一个版本。 这种方法的优点是，失败的团队不会延迟产品交付，也不会尝试执行未完成的任务。 这样一来，专案人员就不会在晚上撕毁手机，并且值班组早上也不会带着手提袋出现在工作中。 当然，这种方法不适用于外包公司：客户不会为未完成的工作付费。 坦率地说：我喜欢公司的文化，建议您观看有关其运作方式的视频（https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/）。
订票
这些家伙也很酷。 它们的发布基于A / B测试。 假设有一个当前的稳定版本-版本A，并且有一个开发人员刚刚完成的版本-版本B。如果KPI在版本B中更好，那么值得增加此版本的用户比例。 如果版本B较差，则有两种选择：版本B只是不稳定或只是没人需要的功能。 这种方法适用于照顾其工作产品的公司，但很可能不会带来革命。 如果您想了解有关精益生产的更多信息，请阅读精益启动书（http://theleanstartup.com/）。