你好 我是俄罗斯LM研发主管Valery Laptev。 两年来，我需要组建一个庞大的部门，这是一次相当有趣的经历。
事实是，Leroy Merlin在许多国家/地区。 法国的母公司称为ADEO。 他们为法国，意大利，西班牙和俄罗斯编写代码。 我们的商业模式是不同的：如果我们在俄罗斯市场上保持最低的价格（低于所有竞争对手的监控价格），那么在欧洲，一切都会有所不同。 实际上，海洋是不同的-从区域特征到其他法规。 俄罗斯基础设施的特点（对哈巴罗夫斯克的延误也非常大）和下订单的另一个生命周期。 所有这些都产生了由巨大的IF块组成的地狱代码：
两年前，我们有60家商店，并且有很多愿望清单功能。 他们滚动了大约六个月，但并非总是正确。 一堆被低优先级拒绝的功能之后的最后一根稻草是请求按顺序输入行字段，以便我们稍后进行解析。 这对于俄罗斯的交货功能是必要的，因为该国比其他存在LM的国家要大。 他们拒绝了我们，或更确切地说，他们说它将在七到八个月内出现。
悠闲的母公司的半年周期不适合我们。 自然，我们建议编写自己的代码，将其提交给审阅并等待实现。。。确实，这没什么好处。
为什么功能实施缓慢？
故事很简单：尽管我们拥有数十家商店，但我们并不是世界上第一家。 有法国（上级组织所在的地方）的需求，也有其他国家的需求。 根据可能为一组公司带来的利润或成本降低的优先级，并按此顺序执行。 也就是说，我们的功能几乎从未实现过，除非非常幸运，并且以某种冲刺的方式，有人会更早地完成任务并去分解待办事项的底部。
第二个功能是，当您将任何功能滚动到master分支中（在此旧版IF-IF-IF代码中）时，您需要检查其在其他国家/地区的行为。 让我引用Bash的
441869 ：
程序员：好吧，想象一下您是一名作家，并且支持“战争与和平”项目。 您拥有传统知识-写一章讲述娜塔莎·罗斯托娃在雨中如何在公园散步。 您写道-“下雨了”，保存，错误消息飞出：“ Natasha Rostova已死，无法继续。” 她为什么死了？ 您开始了解。 事实证明，皮埃尔·别祖霍夫（Pierre Bezukhov）的滑鞋摔倒了，枪击中了地面并击中了一根柱子，子弹从柱子上弹跳到了娜塔莎（Natasha）身上。 怎么办 充电枪空闲吗？ 换鞋吗？ 我们决定卸下支柱。 我们得到消息：“ Rzhevsky中尉死了。” 事实证明，在下一章中，他依靠的支柱不再是...
一般而言，当我们为巴西某处的俄罗斯票房介绍一些内容时，可能会有人反弹。
这意味着非常大的测试范围，漫长的预发布过程，并且通常不愿维护快速增长的代码。 因此，功能越少-越好。 但是你坚持。
总体上来说，这个职位是可以理解的，我只是在母公司的网站上做。 因为这是理性的。
解决问题
第一种方法是在额头上：我们建议打开一个代码，以便我们在那里进行拉取请求。 假设大约有10个开发人员可以快速地编写关键业务功能代码，并将其交给法语，然后他们将按照自己的程序进行测试，一切都会很好。
实际上，这些人已经是：我们正致力于消除从其他国家/地区获得的额外业务逻辑，例如各种累积折扣和异常库存（在我们的业务模型中这是根本不可能的），并在此处放置了虚拟对象。
ADEO的法国人希望有一个发布周期，以便自己滚动和安装新版本。 接受了我们关于一个分支进行实验的报价。
放弃访问，开始接受代码进行审查。 事实证明它还是很慢。 推出数月-并非如此。 赢了好几个星期，但是这个过程仍然不合适。
然后，六个月以来，在内容部分（管理客户看到的产品数据）中对我们重要的功能没有出现。 我们坐了六个月没有释放。 他们的功能没有运行，或者测试没有通过，那么他们并没有意识到我们到底需要什么。 结果，我们长时间坐在一个关键系统上而没有更新。 前面有NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular。 在代码中，由于存在许多考古层，因此遇到了一些问题，例如滥用SQL数据库和非关系数据库。 在其中一个地方，获取了大量的主数据，将其插入SQL数据库的一个字段中，然后拆分为NoSQL数据库中的实体。 在显示商品的网站的一页上，有数十个这样的请求。 随着对这一遗产的进一步了解，身体不同部位的头发开始移动。 我们了解到，头部的传统分层面临着哪些特殊性。
自己发展
第一个想法是一起做功能。 当场，即在法国。 我们四个人去了法国，开始坐在我们的同事旁边，共同了解一切，并根据需要做。
没用 一样，一切都很缓慢。
第二个想法是分叉所有已经存在的并逐步完成。 我们在建筑委员会中坐下来，评估了前景，计算了大概的开发计划，并意识到我们需要选择其他方法。 具体来说，是的，可以分叉，但不开发现有代码，而是将整体拆分成多个部分并将微服务放在需要的地方。
也就是说，我们计划以代码的形式重写整个逻辑块。 为此，他们开始将部分服务转换为我们可以完成的工作。 我们开始招募开发人员。 然后，我们完全跟随母公司的堆栈-Java，Spring，并且一切都在附近，而不是Couchbase是Mongo（这与NoSQL类似）。
随着项目的发展，我们意识到我们需要以自己的方式做很多事情（因为它更快，更容易，以便特别是不需要我们不需要的遗产），并开始扩展到其他技术。 然后是Java 7，Wildfly（以前称为JBoss）和SVN。 我们问为什么他们不迁移到Java 8，GIT和Tomcat。 原来，他们不介意，但过了几年。 同时，亲爱的，在旧堆栈上写。 因此，我们逐字逐句地决定完全分开。 商业部门理清了这个问题，什么是利弊，并全力支持。
几乎立即投入了大约30％的代码，并编写了许多微服务。 从他们没有接触到的事实来看，这几乎是金钱交易业务流程的整个核心。
自然，我们首先想到的是如何区分发展领域。 我也将单独讨论这个问题，但是总的来说，该方案如下：
水平是业务领域。 例如，与客户关系有关的所有内容（第一个绿色单元）都是一个区域，并且一个部门有一组应用程序。 目标函数的这种分离在不同的位置创建了多个代码副本，并且需要良好的公司总线（同样，是一个单独的故事），但是它使您可以清楚地找到目标并解决问题，直到得出结果。 经过将近三年的研究，我可以说架构是正确选择的，但是如果我知道我现在所知道的，我将进行一些更改。
现在我们得出的结论是，在一般结构中，有许多功能团队组成了大型产品团队。 同时，产品团队不仅包括开发人员本身，还包括设计师和业务代表。 由于公司的任何IT部门的最终目标要么是为了提高业务开发的速度，要么是由于自动化而降低成本，因此我们需要这些团队中的业务代表。 零售全部与IT有关。 没有一个过程可以称为“无法接近”。
功能团队是一小部分人（通常是分析师，测试人员，后端开发人员和前端开发人员，ops）。 分析人员通常扮演产品所有者的角色，或者来自企业的人来到这里。 所有者有积压，优先级，任务。 他决定了它们的发展。 开发人员自己选择实现选项，在团队中讨论将要做什么以及如何做。 我们没有团队负责进行任务评估，编码和决策。 每个人都做。 通常，经验丰富的团队成员会提出许多人愿意依靠的意见。 但是任何人都可以做出决定。 当然，当两个开发人员无法就功能的实现达成一致时，就会发生冲突。 如果冲突变成了人格-您需要升级。 但是，大多数情况是选择实施解决方案。 然后，每个人都会站起来并靠近董事会，直到找到适合所有人的选项。 通常情况下很快就会发现，但是有时候他们会整天争论不休。 当争论陷入僵局时，通常被称为裁判员-来自另一个团队的人，每个人都信任他的观点。 他们解释了问题的实质，他解决了。 甚至是6月或受训人员都可以参加这场争端的理论讨论，但我只知道其中几个这样的案例-通常，这些傻瓜都有导师来听他们讲。
特征团队的一个例子：我们有一个服务平台，使您可以与承包商一起购买商品和服务。 例如，我买了一扇门-您可以立即放入篮子并安装，这样一来，一个独立的主人就可以根据我们的标准来工作。 我们将检查并付款，并提供保证。 因此，这个团队生产了一个产品，为此它编写了IT解决方案，并制定了业务决策，更改了商店中的流程。 同意承包商。 在那里-业务产品的所有者，商店的业务员，架构师，开发人员，分析师和测试人员。 他们立即使用我们的企业API平台来回传递所有数据并编写微服务。 这种方法-立即由操作人员和业务人员与开发人员和小型团队合作-使您可以快速创建产品。 但是，我认为，最好以后他们自己告诉您从内部看它的外观。
最初，我们不想做单独的测试人员：趋势是，开发人员应该遵循TDD方法或自己测试自己的代码直到最后。 实际上，它不是很有效。 一开始一切都很好：写了-你回答。 您需要测试才能使您的应用程序正确运行。 但是，任务和应用程序越多，难度就越大。 有些应用程序消失了，有些转到了产品目录，几个月都没有变化。 编写测试，维护测试等等变得越来越困难。 团队分析师已经改变。 相对较新，他们同意错了：需要测试人员。 但是开发人员不会停止编写测试，有时会停止进行TDD。 我们自己意识到，检查功能（应用程序正确运行）的测试以及验证应用程序在有问题的情况下运行的测试应该由不同的人来完成。 第二，需要测试人员，因为他们不仅涵盖单元测试，还涵盖了可能的奇怪情况。
现在有60个纯开发人员-背面，正面，全栈。 也有分析师，测试人员和支持。 以及另外七个devops。 但是，仍然没有从头衔中招募200名计划人员，因此我们正在寻找新人才，因为工作领域巨大。 如果有的话，
我的圈子中有空缺。 也就是说，从发展来看，我们现在大约有200个中的74个。
内部来源
鉴于我们仅在俄罗斯有许多独立的团队，并且在其他许多国家还是有类似的团队，所以我们正在朝
innsource的方向
发展 。 这与有限的一群人中的开源非常相似。
在所有国家/地区部门的ADEO组中，所有代码都位于云github中。 该项目是根据统一的设计规则制定的。 对样式，技术和工具没有任何限制。 当您拥有开源代码并制定清晰的设计规则时，堆栈上的所有开发人员都可以做出贡献。 要将您复制到代码中，您需要阅读扩展坞，克隆存储库，进行编辑，发送拉取请求。
目前，巴西，俄罗斯和法国正在非常积极地利用这一共同基础。
现在，我们正在尝试将承包商的全部代码（而且我们在不同方向上有很多代码）转移到InnerSource。 在分析中，我们在两个轴上创建了一个映射：一个轴上的内圆模式和第二个轴上的内圆模式转移的技术复杂性，向内圆的转移通常有用多少。 如果代码是唯一的，并且只需要在一个地方使用-也许您甚至都无需触摸它。 但是，如果有许多团队使用此站点，则肯定是必要的。
所有这些总体上增强了发展文化。 而且它可以加快几个团队的速度，因为您可以针对所需的任何功能编写合并请求。 所有者团队将使用它，并由贡献者对其进行测试。 重要条件之一是自动测试的可用性以及存储库中任何代码的描述。
更多细微差别
当他们开始时，什么都没有。 与开发人员同时，他们招募了开发人员。 现在，devobservices要么作为服务提供（针对需要的人），要么产品团队拥有自己的操作，而操作已经确定了什么以及如何进行。
汇编是在Jenkins中完成的，代码是在Sonar中运行的（更确切地说，已经是SonarQube）。 声纳失败-没有释放。 测试人员编写自动测试，代码所有者-功能测试。 数据库是基础架构工程师提供的服务。 由于测试库的结构和主要库的结构不同，因此在极少数情况下会进行全负载测试：在预生产平台上，我们拥有随机数据，而不是匿名的真实数据（这是将来的步骤之一），因此您需要轻轻滚动而不是一次滚动。
很快，我们应该确定过渡计划并就基础架构中的所有细节达成共识后，就应该去Kubernetes（并且最初已经有一些新产品，例如
市场 ）。
我和我的同事们将继续谈论工作的安排方式，因为几乎每个地方您都可以无限进行。 好吧，您可以关注我们的真人秀（因为所有内容都在构建且变化很快），然后打赌我们是否会搞砸它。