移动应用发布流程_为您的移动应用找到正确的发布策略

移动应用发布流程

When you’re developing apps, at some point you need to release updates to your users. There are benefits to releasing updates frequently, but there are lots of factors that make it hard to do.

在开发应用程序时，有时需要向用户发布更新。 频繁发布更新有很多好处，但是有很多因素使它难以执行。

In this article, I’ll explain why it’s good to make regular releases, what can get in the way of doing that, and outline some strategies that you could use on your project to help you get your releases out more regularly.

在本文中，我将解释为什么发布常规版本很好，这样做有什么用，并概述了一些可用于项目中的策略，可帮助您更定期地发布版本。

为什么最好经常发布更新 (Why It’s Good to Release Updates Frequently)

用户喜欢新功能 (Users like new features)

Users want to see new features, improvements, and bug fixes — particularly if they’ve paid for the app or a subscription to it. Releasing regularly shows users that the app is valuable and evolving.

用户希望查看新功能，改进和错误修复-尤其是如果他们已经为该应用程序或对该应用程序的订阅付费。 定期发布会向用户显示该应用程序有价值且不断发展。

However, there’s a caveat to this. Moving features around and changing behaviour can be confusing and harm your app’s user experience, so it’s important to manage how change is released. Little and often is a good way to go.

但是，有一个警告。 移动功能和改变行为可能会造成混乱，并损害您应用程序的用户体验，因此管理更改的发布方式非常重要。 少而又经常是一个好方法。

少量发行风险较小 (Small releases are less risky)

The smaller the release, the smaller the risk of releasing.

释放越小，释放的风险越小。

Say you’re releasing one feature. Despite all the preparation you have done, there is a serious bug. Whilst this isn’t ideal, it’s manageable. You fix the bug and you update it, and your broken app is on the app store for a minimal amount of time.

假设您要发布一项功能。 尽管您已进行了所有准备工作，但仍有一个严重的错误。 尽管这不是理想的方法，但它是可管理的。 您修复了该错误并对其进行了更新，并且损坏的应用程序在应用程序商店中的停留时间最少。

Now imagine you release ten features at once, and you manage to introduce ten serious bugs. If that actually happens, you probably have more to worry about than your release strategy, but it illustrates the point. You would be in a bad situation, trying to fix ten serious bugs and get an update out as soon as possible. To minimise your risk, keep your releases smaller and more frequent.

现在，假设您一次发布了十个功能，并且设法引入了十个严重的错误。 如果确实发生了这种情况，那么您可能比发布策略要担心的更多，但这可以说明这一点。 您可能处境很糟，尝试修复十个严重的错误并尽快进行更新。 为了最大程度地降低风险，请使发布更小，更频繁。

创造价值 (Delivering value)

In agile software development, we often talk about the importance of delivering value. What that means is getting the end result of expensive development hours out to users as soon as you can, rather than storing them up in unreleased repositories. The longer software remains unreleased, the more likely it is that it will degrade and require further work before being released, or, worse still, that it will never be released at all.

在敏捷软件开发中，我们经常谈论提供价值的重要性。 这意味着要尽快将昂贵的开发时间的最终结果告知用户，而不是将其存储在未发布的存储库中。 保持未发布状态的时间越长，它就越有可能降级并需要进一步的工作才能发布，或者更糟糕的是，它永远不会被发布。

释放的方式 (What Gets in the Way of Releasing)

You might aspire to releasing updates frequently, but it can still be difficult. Understanding the factors that prevent you from doing so is the first step to getting a successful strategy in place. Here are some of the most common scenarios.

您可能希望经常发布更新，但这仍然很困难。 了解阻碍您这样做的因素是制定成功策略的第一步。 以下是一些最常见的方案。

只是一项功能 (Just one more feature)

Release creep is a common trap that’s easy to fall into. You’re almost ready to release, and someone says, “feature x is nearly ready, can we just get that in as well.” And when feature x is done, you may as well wait for feature y. The problem is there’s always another feature on its way — your release gets bigger, and the time since your last release gets longer.

释放蠕变是很容易陷入的常见陷阱。 您几乎已经准备好发布了，有人说：“功能x差不多已经准备好了，我们是否也可以将其引入。” 并且当功能x完成后，您也可以等待功能y 。 问题在于，总是有另外一个功能在起作用–您的发行版越来越大，而自上一个发行版以来的时间越来越长。

Tips for avoiding release creep:

避免释放蠕变的提示：

• Plan what’s going into your next release upfront, and stick to your plan.
  提前计划下一个发行版中的内容，并遵守您的计划。
• Keep releases small and frequent, so if a feature has to wait until the next release it won’t be too long.
  保持较小且频繁的版本，因此，如果功能必须等到下一个版本发布，它就不会太长。

外部依赖 (External dependencies)

External dependencies can easily block releases.

外部依赖关系可以轻松阻止发布。

Consider a new feature in the app that requires a change to a backend API. Let’s say you’ve added the feature to your code, but the new API hasn’t been released yet. If your app doesn’t work without that API feature, you’re now in a position where you can’t release an update. This also blocks the release of subsequent features and makes it much harder to release emergency fixes.

考虑应用程序中的一项新功能，该功能需要更改后端API。 假设您已将功能添加到代码中，但是尚未发布新的API。 如果您的应用没有该API功能就无法运行，那么您现在处于无法发布更新的位置。 这也阻止了后续功能的发布，并使发布紧急修复程序变得更加困难。

This is surprisingly common in practice. I’ve seen commercial app projects that have spent months building an app, only to have to delay the release of the app by months, or even years, because required external dependencies weren’t completed.

在实践中这是令人惊讶的普遍现象。 我已经看到商业应用程序项目花了几个月的时间来构建应用程序，而只是由于未完成所需的外部依赖关系而不得不将应用程序的发布推迟数月甚至数年。

Tips for avoiding delays due to external dependencies:

避免因外部依赖而造成延迟的提示：

• Avoid starting work on features until external dependencies are available in your production environment.
  在生产环境中可以使用外部依赖项之前，请避免开始使用功能。
• If you can’t guarantee external dependencies being available, use feature switches to hide features from users until the external dependencies are available.
  如果不能保证外部依赖关系可用，请使用功能开关对用户隐藏功能，直到外部依赖关系可用为止。

未完成的功能 (Unfinished features)

You can’t release if your code contains features that aren’t ready for users to see. Maybe the UI isn’t finished, or it hasn’t been fully tested or approved for release. This can be more of an issue if you’re working in a team because it can be hard to line up multiple features to be finished at the same time. And if the code isn’t in a state to release, it can be tempting to start a new feature while the other one is being finished, and before you know it, you’ve got release creep.

如果您的代码包含的功能尚无法让用户看到，则无法释放。 用户界面可能尚未完成，或者尚未经过全面测试或批准发布。 如果您在团队中工作，这可能是一个更大的问题，因为很难同时完成多个功能。 而且，如果代码没有处于发布状态，则可能很想在另一个功能完成的同时启动一个新功能，并且在不知不觉中，您就已经发布了蠕变。

Tips for managing unfinished features:

管理未完成功能的提示：

• Plan which features are going into your release in advance. Once they are complete, don’t start any more until your release is done. It can help if team members a pair on any remaining work to get the release over the line.
  提前计划哪些功能将包含在您的版本中。 一旦完成，在发布完成之前不要再开始。 如果团队成员在剩下的任何工作上结成对，则可以提供帮助，以在线发布。
• Don’t start a new feature until the last thing you were doing is finished, tested, approved, and ready to release.
  在您完成最后一件事，测试，批准并准备发布之前，不要启动新功能。
• Plan your work into small, deliverable chunks that can be released independently to users.
  将您的工作计划为可交付的小块，这些块可以独立发布给用户。
• Consider using feature switches to allow work to be included in your codebase without being visible to users.
  考虑使用功能开关，以允许工作被包含在您的代码库中而对用户不可见。

发布需要时间和精力 (Releasing takes time and effort)

When you release an app to the app store, there are various processes that you need to complete. You’ll need to test your app, archive it, upload it to the store, prepare the store page with marketing information and screenshots, put your app through review, and finally release it to end-users. While many of these steps can be automated, there almost always has to be some level of manual intervention. If your release takes too much effort, you’ll be reluctant to do it frequently.

将应用发布到应用商店时，需要完成各种过程。 您需要测试您的应用程序，对其进行存档，将其上传到商店，准备带有市场营销信息和屏幕截图的商店页面，对您的应用程序进行审核，最后将其发布给最终用户。 尽管这些步骤中的许多步骤可以自动化，但几乎总是需要一定程度的手动干预。 如果您的发布花费太多精力，您将不愿意经常这样做。

Tips for making your release easier:

使发布更轻松的提示：

• Automate as much of your release process as you can. If you can test, archive, create screenshots, and upload to the store at the touch of a button (or a merge to master), you can remove much of the pain of releasing.
  尽可能使发布过程自动化。 如果您只需按一下按钮(或合并到母版)就可以测试，存档，创建屏幕快照并上传到商店，则可以消除很多发行上的麻烦。
• For anything you can’t automate, create a checklist or a process you can work through quickly and repeatably.
  对于您无法自动化的任何事情，创建一个清单或一个可以快速重复地进行的过程。

复合效应 (The compounding effect)

If you’re in a position where something is stopping you from releasing, it’s easy to end up in a feedback loop. The longer you leave it, the riskier it gets, the more you are affected by external dependencies, and the more time and effort it will take when you finally do release.

如果您处在某种阻碍您释放的位置上，那么很容易陷入反馈循环。 保留的时间越长，风险就越大，您受外部依赖项的影响就越大，最终释放时将花费更多的时间和精力。

发布应用的策略 (Strategies for Releasing Your App)

If you’re struggling to release, I recommend you take stock, take a look at what factors are impacting you, and select a strategy to make things easier. Here are some of my favourite strategies for releasing mobile apps.

如果您在努力发布，我建议您盘点一下，看看哪些因素在影响您，然后选择一种使事情变得容易的策略。 以下是一些我最喜欢的发布移动应用程序的策略。

每项功能发布后发布 (Release after every feature)

This strategy gives the most frequent releases. As the title suggests, every time you complete a feature, you release your app to your end-users. This strategy is good because your users get change little and often, it’s easy to test, it’s low risk, and it delivers value to your users as quickly as possible.

此策略提供了最频繁的发布。 顾名思义，每次完成一项功能时，您都将应用发布给最终用户。 此策略之所以有用，是因为您的用户很少且很少获得更改，它易于测试，风险低并且可以尽快为用户带来价值。

However, if you have more than one or two people in your team, it can be a difficult strategy to manage. You need to ensure that your code is always fully tested and releasable, and the overhead associated with each release can quickly become expensive.

但是，如果团队中有一个或两个以上的人员，这可能是一个难以管理的策略。 您需要确保您的代码始终经过完整的测试和发布，并且与每个发行版相关的开销很快就会变得昂贵。

This strategy works well for:

此策略适用于：

• Single-person teams and hobby projects.
  单人团队和爱好项目。
• Releases that are highly automated.
  高度自动化的发行。

批量发布 (Batched releases)

This is a simple strategy, where you decide when you have enough features to release. You can either plan this in advance, or decide on an ad hoc basis. Once the features are completed, you make the release.

这是一个简单的策略，您可以在其中决定何时发布足够的功能。 您可以预先计划，也可以临时决定。 功能完成后，即可发布版本。

This can be a good strategy because it’s flexible, lightweight, and doesn’t require a lot of processes.

这是一个很好的策略，因为它灵活，轻巧并且不需要很多流程。

However, whilst this is the simplest strategy on paper, it’s probably the hardest to get right. It’s easy to fall into the feature creep trap, and it requires good discipline to stop releases getting too big. It can be hard to get your code in a releasable state, with everyone in the team lining up finished features together. It’s particularly difficult to make this work if the team is new or not working well together, or if there are low levels of trust within the team. Teams often default to this way of working, but I wouldn’t recommend it unless you have a strong team and you apply the strategy intentionally.

但是，尽管这是纸上最简单的策略，但它可能是最难解决的问题。 容易陷入功能蠕变陷阱，并且需要良好的纪律来阻止发行版太大。 在团队中的每个人都将完成的功能排在一起的情况下，很难使您的代码处于可发布的状态。 如果团队是新成员，或者团队合作不力，或者团队内部信任度低，则使这项工作特别困难。 团队通常会默认使用这种工作方式，但是除非您拥有一支强大的团队并且您有意应用该策略，否则我不建议您这样做。

This strategy works well for:

此策略适用于：

• Small to medium teams.
  中小型团队。
• Teams with good delivery discipline.
  具有良好交付纪律的团队。
• Teams with a high level of trust.
  具有高度信任的团队。

Scrum (Scrum)

Rather than being a release strategy per se, this is an entire delivery framework. In scrum, teams work in sprints. These are regular, time-boxed intervals, typically around 2–4 weeks. The features to be delivered are agreed upfront, and released at the end of the sprint. In practice, this is very similar to batched releases, but the framework provides more structure and process to help you get releases out.

它本身不是一个发布策略，而是一个完整的交付框架。 在Scrum中，团队在冲刺中工作。 这些时间间隔是固定的，通常为2-4周左右。 即将交付的功能已预先达成协议，并在sprint结束时发布。 实际上，这与批处理发布非常相似，但是该框架提供了更多的结构和过程来帮助您发布发布。

This strategy is good for getting a managed amount of change out to users at regular intervals. It makes it easy to ensure the code is releasable when it needs to be, and it stops your releases from getting too large. It’s great for developing good delivery discipline, for example in teams that are new or aren’t working well together. And because it sets out expectations and commitments to meet those expectations, it’s good for building trust within teams.

此策略有助于定期将可管理的更改量分发给用户。 它可以轻松确保需要时可释放的代码，并且可以防止发行版太大。 这对于发展良好的交付纪律非常有用，例如，在新团队或合作不佳的团队中。 而且由于它设定了期望和满足这些期望的承诺，因此对于在团队内部建立信任是有好处的。

On the downside, scrum introduces heavyweight processes and ways of working that can slow you down, so I wouldn’t recommend it for teams that are already working well, or where there isn’t a problem that needs fixing.

不利的一面是，Scrum引入了重量级的流程和工作方式，这些流程和工作方式会使您放慢脚步，因此，对于那些已经运行良好或没有问题需要解决的团队，我不建议您这样做。

This strategy works well for:

此策略适用于：

• Teams that are struggling to release.
  努力释放的团队。
• Teams that don’t yet have a good delivery rhythm.
  尚未具备良好的投放节奏的团队。
• Teams with lower levels of trust.
  信任度较低的团队。

“发行火车” (“Release train“)

The term “release train” was coined by Spotify in their Spotify engineering culture presentations and it refers to making releases at regular intervals, regardless of what work has been done. The metaphor is that the release train leaves the station at regular intervals. Features that are ready, make the train, i.e. they go in the release and are released to users. Features that aren’t ready miss the train and wait for the next one.

“发布培训”一词是Spotify在其Spotify工程文化演示文稿中创造的，它指的是定期进行发布，无论完成了什么工作。 隐喻是，释放列车要定期离开车站。 准备就绪的功能使培训成为可能，即它们已发布并发布给用户。 尚未准备就绪的功能会错过火车，等待下一场。

This strategy is good for establishing releases at regular intervals. Change is released in small batches, at a manageable frequency. It is good for demonstrating progress and delivers value to users regularly.

此策略适合于定期创建发布。 变更以可管理的频率小批量发布。 它有利于演示进度并定期为用户提供价值。

The downside is that you need a good way of managing features that aren’t ready for release, for example, feature switches. This introduces a lot of complexity and management. In bigger teams this is well worth the cost and effort, but in smaller teams I’d recommend thinking carefully before introducing it.

缺点是，您需要一种好的方法来管理尚未准备发布的功能，例如功能开关。 这引入了很多复杂性和管理。 在较大的团队中，这是值得付出成本和精力的，但是在较小的团队中，建议您在引入它之前仔细考虑。

This strategy works well for:

此策略适用于：

• Medium to large teams.
  中大型团队。
• Projects with good levels of automation.
  具有良好自动化水平的项目。
• Well established teams with strong processes.
  拥有完善的团队和强大的流程。
• Projects where you want to make frequent and regular releases.
  您想经常发布的项目。

摘要 (Summary)

In this article, I described why it’s good to make frequent updates to your app, and what can stop you from doing that. Then I outlined some of my favourite strategies for releasing mobile apps. Thanks for reading, I hope you found it useful.

在本文中，我描述了为什么经常更新应用程序是件好事，以及阻止您这样做的原因。 然后，我概述了一些我最喜欢的发布移动应用程序的策略。 感谢您的阅读，希望您觉得它有用。

[R物资跟不上 (Resources)

• Spotify engineering culture presentations

  Spotify工程文化演示

• What is scrum?

  什么是Scrum？

翻译自: https://medium.com/better-programming/find-the-right-release-strategy-for-your-mobile-app-ba1bce3d7fa2

移动应用发布流程