中国最重要的位置标志是_功能标志对于管理人员和开发人员都非常重要

最新推荐文章于 2024-10-08 20:27:53 发布

Big黄勇

最新推荐文章于 2024-10-08 20:27:53 发布

阅读量508

点赞数

文章标签： python java android linux

原文链接：https://towardsdatascience.com/feature-flags-are-valuable-for-managers-as-well-as-developers-1c33bb4085fc

版权

中国最重要的位置标志是

部署期间为每个人带来舒适感 (BRINGING COMFORT TO EVERYBODY DURING DEPLOYMENTS)

How do you deploy a new feature in production? Do you create a new release of your application and then push it to production? Can the preceding release already contain the code?

您如何在生产中部署新功能？您是否创建了应用程序的新版本，然后将其推向生产环境？先前的版本可以包含代码吗？

For years, I have seen development teams coupling the launch of a new feature with the deployment of a release. And when the feature was not working properly, the only solution was to rollback the whole release, losing all other changes.

多年来，我已经看到开发团队将新功能的发布与发布的发布结合在一起。并且，当该功能无法正常运行时，唯一的解决方案是回滚整个发行版，并丢失所有其他更改。

持续交付 (Continuous Delivery)

Continuous Delivery introduced a new idea: every single change leads to the delivery of the code, which can either be automatically deployed to production (Continuous Deployment) or require a manual action (Continuous Delivery). Working this way requires the ability to enable/disable the usage of a feature, and this exactly what Feature Flags are designed for.

持续交付引入了一个新想法：每一个更改都会导致代码交付，代码可以自动部署到生产中(持续部署 )，也可以要求手动操作(连续交付 )。以这种方式工作需要具有启用/禁用功能使用的能力，而这正是功能标记的目的所在。

Image for post — Difference between Continuous Delivery and Continuous Deployment — illustration by author

But please note that Continuous Delivery is not a prerequisite to use Feature Flags. It might be desirable to decouple a business go-live from a technical deployment, regardless the way of working.

但是请注意， 连续交付不是使用功能标志的先决条件 。无论工作方式如何，都可能需要使业务上线与技术部署脱钩。

功能标志改变了我们的生活 (Feature Flags changed our (go-)lives)

As an architect, I am deeply convinced that Continuous Delivery is the future for a team like mine — and the whole company. And because my teammates and manager agree with this vision, we have been working hard to reach this target.

作为一名建筑师，我深信“持续交付”是像我这样的团队以及整个公司的未来。由于我的队友和经理都同意这一愿景，因此我们一直在努力实现这一目标。

Deploying our applications several times a week (or a day) for our daily business is a great achievement but the truth is we were still struggling to launch a new feature. At the time, a feature was enabled or disabled via some config shipped with the app, and the only way to activate a feature was to update the config, i.e. release and deploy the app again.

每周(或每天)几次为我们的日常业务部署应用程序是一项巨大的成就，但事实是我们仍在努力推出一项新功能。当时，该功能是通过应用附带的一些配置启用或禁用的，激活该功能的唯一方法是更新配置，即再次释放并部署该应用。

To solve this pain point, I proposed to implement a system of Feature Flags, which is far from a revolution but little known and often underestimated. The idea is to have a system to toggle a feature, that can be queried to determine whether the given feature is active. Pete Hodgson says it all in his brilliant article on Martin Fowler’s blog:

为了解决这一难题，我建议实施一个功能标记系统，该系统距离革命还很远，但是鲜为人知，而且经常被低估。想法是要有一个系统来切换功能，可以查询该系统以确定给定功能是否有效。皮特·霍奇森(Pete Hodgson) 在马丁·福勒(Martin Fowler)博客上的精彩文章中说了这一切：

Feature Toggles are a powerful technique, allowing teams to modify system behavior without changing code.

Feature Toggles是一项强大的技术，可让团队无需更改代码即可修改系统行为。

制造或购买 (Make or buy)

When I presented the idea to the management, I was told that maybe we should buy a tool for this — and that would be great if such a tool could also do A/B testing and other sexy features. Of course, it makes sense to consider all options here, and to take the good decision according to the company constraints and capabilities.

当我向管理层提出这个想法时，有人告诉我也许应该为此购买工具-如果该工具还可以进行A / B测试和其他性感功能，那就太好了。当然，在这里考虑所有选项并根据公司的限制和能力做出正确的决定是很有意义的。

I advocated for making our own for this time for a few reasons, among others:

我主张这次创建自己的网站有以下几个原因：

Our architecture was made of distributed and scalable microservices, and I knew that creating a new one for Feature Flags would go fast and immediately fit our needs.
我们的架构由分布式和可扩展的微服务组成，我知道为功能标记创建一个新的微服务将很快并立即满足我们的需求。
Although it definitively can be useful at some stages, A/B testing was a bit out of scope for a first step, as it would not solve our technical deployment concerns. The complexity overhead here might slow down its commissioning and buying a tool also implies a non-negligible integration effort.
尽管它在某些阶段肯定有用，但第一步的A / B测试有点超出范围，因为它无法解决我们的技术部署问题。这里的复杂性开销可能会减慢其调试速度，购买工具也意味着不可忽略的集成工作。

Finally, the management trusted me and gave the green light for a light-weight PoC with limited scope (no A/B testing, focus on technical features). After just one sprint, the component was ready because our infrastructure is designed for this, and developing microservices is our daily business.

最后，管理层信任我，并为范围有限的轻量级PoC(未进行A / B测试，专注于技术功能)开了绿灯。只需进行一次冲刺，组件就准备就绪，因为我们的基础架构是为此目的而设计的，开发微服务是我们的日常业务。

保持简单愚蠢(KISS) (Keep It Simple Stupid (KISS))

The proposed service has been designed as a simple RESTful API, binding the usual CRUD operations:

提议的服务已被设计为简单的RESTful API，绑定了通常的CRUD操作：

Note that the PATCH method is used instead of the PUT since we only apply a partial update of the Feature resource (only status and last modification info).

请注意，由于我们仅对Feature资源进行了部分更新(仅状态和最后修改信息)，因此使用PATCH方法代替了PUT 。

The component relies on its own dedicated relational DB, with one single basic table made of few columns: name, status, expiration date, creation and modification info.

该组件依赖于自己专用的关系数据库，其中一个基本表由几列组成：名称，状态，有效期，创建和修改信息。

There is almost no logic in the application, requests are transformed and given to the DB. We just implemented a few additional security and caching layers for obvious reasons:

应用程序中几乎没有逻辑，请求被转换并提供给DB。出于明显的原因，我们仅实现了一些附加的安全性和缓存层：

Tracing — it is desirable to keep track of who toggled a feature, and of course to check their privilege level in the first place.
跟踪-最好跟踪谁在切换功能，当然首先要检查其特权级别。
Stability — it is essential to avoid creating a single point of failure, especially given that the system may face an important load (there are many stories of unresponsive systems because of a DoS that was generated by too many internal calls).
稳定性-避免造成单点故障非常重要，尤其是考虑到系统可能面临重要的负载(由于内部调用太多而产生的DoS导致系统无响应的情况很多)。

Another crucial point is the capability to manage errors from the clients calling this API, when the service does not respond for some reason. There are traditional patterns for this, like timeout, circuit-breaker, etc.

另一个关键点是当服务由于某种原因没有响应时，能够管理来自调用此API的客户端的错误。有一些传统的模式，例如超时，断路器等。

习惯 (Getting used)

The adoption of this new mechanism took a few days until every IT team had a chance to launch some new technical feature (or disable some old ones) but every developer was very positive about it, because it greatly facilitated the go-lives, with a considerable reduction of stress level.

这种新机制的采用花了几天的时间，直到每个IT团队都有机会启动一些新技术功能(或禁用某些旧功能)，但每个开发人员都对此表示非常肯定，因为它极大地促进了上线工作。大大降低了压力水平。

Just a few weeks later, our company was strongly impacted by the COVID-19 crisis, and as an e-grocery company, we had to adjust many business processes to support the sudden demand we were facing.

仅仅几个星期后，我们公司就受到了COVID-19危机的严重影响，作为一家电子杂货公司，我们不得不调整许多业务流程以支持我们面临的突如其来的需求。

I was more than pleased to see that in such critical times, developers intensified the move to toggles. Very often, when things get harder, people choose to flip back to the former, traditional, legacy way of working, but this was not the case here.

我很高兴看到在这样的关键时刻，开发人员加大了切换的步伐。很多时候，当事情变得更加艰难时，人们选择转而使用以前的，传统的，遗留的工作方式，但事实并非如此。

即时优势 (Immediate advantages)

In my humble opinion, this was the time when many people did realized the incredible benefits of Continuous Delivery coupled to Feature Flags: IT teams were able to go fast, developing urgent features in a short time, which were immediately pushed to production, and features activation was just one click away — or more likely, one curl away.

以我的拙见，这是许多人真正意识到持续交付与功能标记结合的不可思议的好处：IT团队能够快速发展，在短时间内开发紧急功能，并立即投入生产和功能。只需单击一次即可激活，或者更可能是一次curl 。

Moreover, as the Feature Toggles service is exposed, it can be reached by any application in our constellation, so that every part (front end, back end, mobile, etc) is immediately aligned when a feature is activated.

此外，由于“功能切换”服务已公开，因此我们星座中的任何应用程序都可以访问该服务，因此激活功能时，每个部分(前端，后端，移动设备等)都将立即对齐。

Another interesting benefit here is that not only can features be activated but also deactivated very quickly, which is quite comfortable as it is way easier than a full rollback.

这里的另一个有趣的好处是，不仅可以激活功能，而且还可以非常快速地停用功能，这很舒适，因为它比完全回滚要容易得多。

局限性 (Limitations)

It would be naive to think that there are only advantages in setting Feature Flags up to the architecture. One drawback in particular is the additional complexity for every client calling the service. This code must be maintained and tested, and after the feature has been launched, it has to be cleaned up.

认为将功能标志设置为体系结构仅存在优势是天真的想法。特别地，一个缺点是每个调用该服务的客户端的额外复杂性。必须维护和测试该代码，并且在启动功能后必须对其进行清理。

This brings us to another threat: having too many Feature Flags can be counter-productive. Again, Pete Hodgson warns us about this in his article:

这给我们带来了另一个威胁：过多的功能标志可能适得其反。再次，皮特·霍奇森(Pete Hodgson)在他的文章中警告我们这一点：

Feature Flags have a tendency to multiply rapidly, particularly when first introduced. They are useful and cheap to create and so often a lot are created. However toggles do come with a carrying cost. They require you to introduce new abstractions or conditional logic into your code. They also introduce a significant testing burden.

特征标记具有Swift繁殖的趋势，尤其是在首次引入时。它们既有用又便宜，因此经常创建很多东西。但是，拨动开关确实会带来账面成本。它们要求您在代码中引入新的抽象或条件逻辑。它们还带来了巨大的测试负担。

To mitigate the risk, we adopted the strategy consisting in creating a story in the backlog as soon as a Feature Toggle is inserted, so that cleaning tasks can be on our radar during grooming (or backlog refinement) sessions.

为了降低风险，我们采用了一种策略，该策略包括在插入功能切换后立即在积压中创建故事，以便在修饰 (或积压细化 )会话期间将清理任务放在我们的雷达上。

We also defined a recommended workflow to help developers to use the tool, with some guidelines. Typically, a naming convention was necessary, since the feature name is the identifier.

我们还定义了建议的工作流程，以帮助开发人员按照一些准则使用该工具。通常，由于功能名称是标识符，因此必须使用命名约定。

结论 (Conclusion)

Feature Flags boosted our productivity, reduced our stress during deployments, and gave the product owners (or managers in general) the ability to activate a feature based on business constraints, not technical release trains. I believe the agility we all gained here is priceless, as the time-to-market is slightly reduced, and the control increased.

Feature Flags提高了我们的生产力，减轻了部署过程中的压力，并使产品所有者(或一般的经理)能够根据业务限制而非技术发布培训来激活功能。我相信我们所有人在这里获得的敏捷性都是无价的，因为上市时间略有减少，控制权也有所增加。

In the end, everybody wins: developers, managers, product owners, and finally customers. Definitively a good move.

最后，每个人都赢了：开发人员，经理，产品所有者，最后是客户。绝对是个好举动。