我一直想在服务中提出一些新的和必要的东西。 特别是如果用户喜欢此服务。 但是，您从哪里得到这些想法？ 如何确定优先级？ 以及如何在不损失任何重要信息的情况下快速将创意引入产品？
我的名字叫Alexander，我领导Yandex.Market的界面开发小组之一。 今天，我将向哈勃（Habr）的读者介绍我们解决这些问题的经验。 我们还考虑了将功能交付到生产中的示例。
团队
Yandex.Market是俄罗斯最大的商品选择和价格比较资源。 每天有350万人使用它-他们在这里计划未来的购买，讨论产品并帮助其他人做出正确的选择。
现在，Yandex.Market拥有40名前端开发人员，并且数量还在不断增长。 是的，有40个人-这只是市场的前端，还有我们其他两个项目的前端-Beru和Bringly的市场。 在2005年，市场中只有5个开发商。
思想源于我们的循环。 因此，我们称呼由不同专家组成的团队。 通常，电路包括：项目（又名产品技术人员），后端，前端，分析师，设计人员和测试人员。 这样的团队可以独立开发服务中的某些内容并解决任何复杂的问题。 此外，每个电路都有明确的职责范围-工作所在产品中的某个“功能电路”。
例如，我们有：
-转换循环-处理UX，搜索，过滤和排序工具；
-通讯电路-为我们的用户制作新闻通讯和促销活动；
-收益轮廓-处理折扣，现金返还，促销代码；
-社区巡回赛-负责评论，评论，讨论，成就，游戏机制和其他UGC。
主意
电路的任何成员都可以提出想法。 我们欢迎所有选择，甚至琐碎或绝对疯狂。 通常，这些家伙会在股东大会上提出想法-这需要整个团队的工作。
为了不丢失任何东西，我们将所有想法分开放在Tracker中-我们的想法库。 收集的想法将根据GIST + ICE框架进行评估。 我们评估每个想法的潜力和实施的人工成本，以决定首先要考虑的是什么。 我的同事
告诉了有关此方法的更多详细信息。
得分最高的想法变成了与客户和表演者一起的项目。 跟踪器中显示了大量的设计任务。 团队负责人为冲刺分配任务，并进入团队。
重要的是，这个想法是由提出它的电路来实现的。 也就是说，这个想法的作者也是它的执行者。 尝试处理您的任务，而不要处理从上方启动的任务-差异会很容易感觉到。
过程
假设我们决定考虑到用户的兴趣，为用户开发商品轮播。
假设循环后台程序已经完成工作，对神经网络进行了培训，API已经准备就绪，已经在测试环境中进行了测试和部署。 收到轮廓设计器的布局，看起来像这样：
仍然需要在前端进行工作并将我们的轮播传送给用户。
市场前端是一个Web客户端和无状态NodeJS服务器，其背后还有许多其他后端：搜索，咨询服务，分析，UGC内容等等。 前端生活在多个DC的Yandex云中。 NodeJS应用程序在容器中执行，并且由于其无状态性质，可以根据需要水平缩放：
市场前端开发人员正在NodeJS上开发服务器端，并在React + Redux上开发客户端。 以一种语言和一种生态系统进行开发非常有效。 如果您仍在考虑统一服务器和客户端之间的技术堆栈，请尝试-这样做很有意义。
为了完成轮播，我们需要在服务器上添加用于接收货物的代码并实现客户端部分。 您可以使轮播变得懒惰-即将轮播显示在屏幕上之前将其加载。 为此，您将必须在客户端API中另外实现终结点。
完成此操作后，开发人员将创建一个池请求，并将其代码发送给代码审查。 我们的代码审查是必须的。 为了使其不会挂起，我们甚至为它的实施提供了推荐的SLA。 您可以
在此处阅读有关我们如何加快代码审查速度的
信息 。
我们正在GitHub Enterprise上开发前端，该前端仅在内部网络上可用。 我们的Github上有一个机器人可以帮助组织代码审查。 机器人本身会找到审阅者，在Messenger中与他们联系，将其添加到GitHub，在Tracker中控制票证状态，并在必要时致电代码的作者。
在GitHub上创建池请求时，发生了很多事情：在测试环境中，产生了一个具有更新的Market的演示站，并将指向该站的访问链接传递到任务凭单。 进行了许多自动检查：lint，格式化程序，单元测试。 运行端到端测试，自动分析客户端应用程序指标。 如果检测到任何降级，则会立即将有关降级的详细报告发送到任务单：
如果所有检查均正常通过，则故障单将自动转换为“您可以检查”状态，并且该任务将出现在质量检查小组的仪表板上。
质量检查工程师拿到任务单并确保已准备好新功能以进行进一步旅行之后，便在该单上标记了一个释放标签。 下一个版本将包含所有带有此标签的票证。
市场通常每天发布1-2次，我们正在努力提高发布频率。 质量保证团队的值班人员参与了发布的准备和发布，发布过程是完全自动化的。 以前，发布包是手工组装的，花费了很多时间。 现在，开发人员可以花时间开发产品。 这加快了向我们的用户交付新功能的速度。
因此，我们的旋转木马推荐产品即将发布。 怎么样了
值班质量检查工程师按下释放按钮。 发布管道开始工作。 可以在
此处查看发布过程报告的演示。 在Tracker中创建一个发行凭单，在GitHub上创建一个发行分支。 所有通过检查的池请求都将自动注入其中。 在测试环境中，出现了带有新版Market的摊位。 在这个展台上，上述所有自动检查都通过了，另外还有很多其他检查。 例如，以恒定负载进行负载测试，并不断增加负载，直到调试测试应用程序为止。 实时分析所有审核日志，生成清晰的报告，并立即将其发送到发行凭单：
质量检查工程师可以一目了然地看到所有阶段，可以评估大量检查的结果。 在新版本的展位上的测试环境中，QA还接受手动测试。 我们经常对新功能进行A / B测试，而不在其上进行端到端测试。
这是发布管道的外观（可单击）：
当发行版通过测试环境中的所有检查后，它将交付给预发行版。 Prestable是另一种环境，但具有作战后端，对真正的Market访客不开放。 一些公司称之为分期。 在这种环境下，还将进行一系列特定的检查和手动功能测试。 如果未发现问题，则将新版本的Market发送给我们的用户，它开始在生产集群中展开。
在准备战斗时，机器人的工作仍在继续。 他们独立地分析应用程序日志，查找服务工作中的异常和降级，并监视客户端指标。 日志监视在该版本发布后会持续一段时间，并且下一版本的Market已在测试环境中进行测试。
值班质量检查还监控发布后市场的运行状况。 他可以使用大量图形-我们使用Graphit和Grafana。 这些图包含了所有内容：从一般的500-k背景到与DC细分的各种后端进行通信时NodeJS应用程序的错误。 我们还有一个单独的人小组-市场健康小组。 她以24/7全天候监控市场指标。
如果检测到问题，则发行版会自动从战斗集群中回滚。 问题已解决，释放已投入战斗。 如果没有问题，则完成发行，将代码合并到master中，关闭进入发行版的票证，并删除项目分支。 所有这一切也会自动发生。
目前，我们的用户已经看到为他们选择的产品，并且电路正在研究新的想法。
这是我们在服务上的轮播：
而不是结论
使您的团队灵活而独立，让他们产生想法，照顾这些想法，对其进行分析-其中绝对有钻石。 请记住，某人在会议期间以不确定，安静的声音表达的想法可能是您的产品及其用户的关键。
让他们的作者尽可能多地体现思想-这样工作会越来越快。 使例程自动化。 花一些时间将想法转化为现实，让机器人来完成其余的工作。
如果读者有兴趣在更详细地谈论某事，请在评论中写下，我会很乐意回答，或者也许我会在新文章中对此进行描述。