Oi Sou Valery Laptev, chefe de desenvolvimento de LM na Rússia. Por dois anos eu precisei criar um departamento enorme, e foi uma experiência bastante interessante.
O fato é que a Leroy Merlin está em muitos países. A empresa-mãe na França é chamada ADEO. Eles escrevem código para a França, Itália, Espanha e Rússia. Nossos modelos de negócios são diferentes: se mantivermos os preços mais baixos no mercado russo (abaixo de todos os concorrentes no monitoramento), na Europa tudo será diferente. De fato, o mar é diferente - das características do local para outra legislação. Existem recursos da infraestrutura da Rússia (os mesmos atrasos muito grandes para Khabarovsk) e outro ciclo de vida para fazer um pedido. Tudo isso gera um código infernal que consiste em enormes blocos IF:
Há dois anos, tínhamos 60 lojas e muitos recursos de lista de desejos. Eles rolaram em cerca de seis meses e nem sempre corretamente. A última gota após um monte de recursos rejeitados por baixa prioridade foi uma solicitação para inserir um campo de linha na ordem, para analisá-lo mais tarde. Isso foi necessário para os recursos de entrega na Rússia, uma vez que o país é maior que outros países de presença da ML. Recusaram-nos isso, ou melhor, disseram que levaria de sete a oito meses.
O ciclo de meio ano da empresa-mãe de lazer não nos convinha. Naturalmente, sugerimos escrever nosso próprio código, submetê-lo à revisão e aguardar a implementação ... É verdade que nada de bom veio disso.
Por que os recursos foram implementados lentamente?
A história é muito simples: apesar das nossas dezenas de lojas, não somos os primeiros do mundo. Existem as necessidades da França (onde está a organização mãe), existem as necessidades de outros países. Eles são priorizados de acordo com a possível redução de lucro ou custo para um grupo de empresas e são executados nesta ordem. Ou seja, nossos recursos são feitos quase nunca, exceto com muita sorte e, em algum tipo de sprint, alguém termina sua parte mais cedo e desmonta a parte inferior da lista de pendências.
O segundo recurso é que, quando você lança um recurso no ramo mestre (aqui neste código IF-IF-IF herdado), é necessário verificar como ele se comporta em outros países. Deixe-me citar
441869 do Bash:
Programador: Bem, imagine que você é um escritor e apóie o projeto "Guerra e Paz". Você tem TK - escreva um capítulo sobre como Natasha Rostova andou no parque na chuva. Você escreve - “estava chovendo”, salve, a mensagem de erro aparece: “Natasha Rostova morreu, a continuação é impossível”. Por que ela está morta? Você começa a entender. Acontece que os sapatos escorregadios de Pierre Bezukhov, ele caiu, sua arma atingiu o chão e atirou em um poste, e a bala do pilar ricocheteou para Natasha. O que fazer Carregar a arma ociosa? Trocar sapatos? Decidimos remover o pilar. Recebemos a mensagem: "O tenente Rzhevsky morreu". Acontece que no próximo capítulo ele se apoia em um pilar que não é mais ...
Em geral, quando apresentamos algo para as bilheterias russas, em algum lugar do Brasil, alguém pode se recuperar.
Isso significa uma cobertura de teste muito grande, procedimentos longos de pré-lançamento e, geralmente, relutância em manter o código que está crescendo rapidamente. Portanto, quanto menos recursos - melhor. Mas você espera aí.
A posição como um todo é muito compreensível, e eu faria exatamente isso no site da empresa controladora. Porque é racional.
Resolução de problemas
A primeira abordagem foi na testa: sugerimos a abertura de um código para fazermos solicitações de extração lá. Supunha-se que houvesse cerca de 10 desenvolvedores sentados lá, que rapidamente e rapidamente codificariam funções críticas dos negócios, os entregariam aos franceses e testariam de acordo com seu próprio procedimento, e tudo ficaria bem.
Na verdade, essas pessoas já eram: estávamos empenhados em cortar a lógica de negócios extra que obtivemos de outros países, como vários descontos acumulados e ações incomuns (que são simplesmente impossíveis com o nosso modelo de negócios) e colocamos manequins nesse lugar.
Os franceses da ADEO queriam um ciclo de lançamento para rolar e instalar novas versões por si mesmos. Aceitamos nossa oferta sobre um ramo para experimentos.
Deu acesso, começou a levar o código para a revisão. Acabou sendo lento de qualquer maneira. Lançamentos por vários meses - esse não é o caso. Bem ganhou algumas semanas, mas ainda assim o processo não se encaixou.
Então, por seis meses, um recurso importante para nós na parte do conteúdo (gerenciamento de dados do produto que o cliente vê) não saiu. Ficamos seis meses sem liberação. O recurso não foi aprovado ou os testes não foram aprovados e eles não perceberam exatamente o que precisávamos. Como resultado, permanecemos em um sistema-chave por um longo tempo sem atualizações. Havia NodeJS + PostgreSQL + Couchbase + Elasticsearch + Angular na frente. No código, devido a várias camadas arqueológicas, foram encontradas coisas, como o mau uso do banco de dados SQL e do banco de dados não relacional. Em um dos locais, uma enorme quantidade de dados mestre foi obtida, inserida em um campo do banco de dados SQL e depois dividida em entidades no banco de dados NoSQL. Em uma página do site com a exibição de mercadorias, havia dezenas e centenas de pedidos. Com uma leitura mais aprofundada desse legado, cabelos em diferentes partes do corpo começaram a se mover. Compreendemos quais peculiaridades do legado em camadas a seção principal está enfrentando.
Desenvolvimento próprio
A primeira ideia foi criar recursos juntos. No local, isto é, na França. Nós quatro fomos à França e começamos a sentar ao lado de nossos colegas para entender tudo juntos e fazer o que precisávamos.
Não deu certo. Mesmo assim, tudo foi muito lento.
A segunda idéia foi bifurcar tudo o que já existe e terminar gradualmente. Sentamos pelo comitê de arquitetura, avaliamos as perspectivas, calculamos os planos aproximados de desenvolvimento e percebemos que precisamos escolher um método diferente. Especificamente, sim, bifurcar, mas não desenvolver o código existente, mas quebrar o monólito em partes e colocar microsserviços onde for necessário.
Ou seja, planejamos reescrever blocos inteiros de lógica na forma de nosso código. E para isso eles começaram a mudar parte dos serviços para o que poderia ser feito conosco. Começamos a recrutar desenvolvedores. Em seguida, seguimos completamente a pilha da empresa-mãe - Java, Spring e tudo o que está por perto, em vez de o Couchbase ser o Mongo (essa é uma base NoSQL semelhante).
À medida que o projeto se desenvolvia, percebemos que precisávamos fazer muitas coisas à nossa maneira (porque é mais rápido e fácil para não oferecer suporte ao legado que não precisamos, em particular) e começamos a expandir para outras tecnologias. Depois, havia Java 7, Wildfly (anteriormente JBoss) e SVN. Perguntamos por que eles não estão migrando para Java 8, GIT e Tomcat. Acabou que eles não se importariam, mas depois de alguns anos. Enquanto isso, queridos, escrevam na pilha antiga. Então, palavra por palavra e decidimos separar completamente. A empresa resolveu a questão, quais são os prós e os contras e a apoiou totalmente.
Quase imediatamente jogou cerca de 30% do código, escreveu muitos de seus microsserviços. Pelo fato de não terem tocado, é quase todo o núcleo da transação de processos de negócios por dinheiro.
Naturalmente, a primeira coisa que pensamos foi em como distinguir entre áreas de desenvolvimento. Eu também falaria sobre isso separadamente, mas em termos gerais, o esquema é o seguinte:
Horizontal é uma área de negócios. Por exemplo, tudo relacionado ao relacionamento com o cliente (a primeira célula verde) é uma área e há um conjunto de aplicativos de um departamento. Essa separação da função objetivo cria várias duplicatas do código em locais diferentes e requer um bom barramento corporativo (novamente, uma história separada), mas permite encontrar claramente os fins e resolver o problema até o resultado. Olhando para isso depois de quase três anos, posso dizer que a arquitetura foi escolhida corretamente, mas se soubesse o que sei agora, faria algumas alterações.
Agora chegamos à conclusão de que na estrutura geral existem muitas equipes de recursos que formam grandes equipes de produtos. Ao mesmo tempo, a equipe do produto inclui não apenas os próprios desenvolvedores, mas também designers e representantes de negócios. Como o objetivo final de qualquer departamento de TI de uma empresa é aumentar a velocidade do desenvolvimento dos negócios ou reduzir os custos devido à automação, precisamos de representantes comerciais nessas equipes. O varejo é tudo sobre TI. Não existe um único processo que possa ser chamado de "inacessível".
Uma equipe de recursos é um pequeno grupo de pessoas (geralmente analista, testador, desenvolvedor de back-end e desenvolvedor de front-end, ops). O analista geralmente desempenha o papel de proprietário do produto ou de uma pessoa da empresa chegar a esse local. O proprietário tem uma lista de pendências, prioridade, tarefas. Ele dita o desenvolvimento deles. O desenvolvedor escolhe a opção de implementação, discutindo na equipe o que será feito e como. Não temos líder de equipe para avaliação de tarefas, codificação e tomada de decisão. Todo mundo faz tudo. Geralmente, os membros da equipe mais experientes dão opiniões nas quais muitos estão dispostos a confiar. Mas qualquer um pode tomar uma decisão. Obviamente, existem conflitos quando dois desenvolvedores não conseguem concordar com a implementação de um recurso. Se o conflito virou personalidade - você precisa de uma escalada na cabeça. Mas a maior parte é a escolha de uma solução para implementação. Então todo mundo fica de pé e se aproxima do quadro até encontrar uma opção que se adapte a todos. Geralmente acontece rapidamente, mas houve casos em que eles discutiram o dia todo. Quando o argumento para, o árbitro é freqüentemente chamado - uma pessoa de outra equipe cuja opinião todos confiam. Eles explicam a essência do problema, ele resolve. Até junho ou estagiário podem participar da teoria nesta disputa, mas eu conheço apenas alguns desses casos - geralmente os jones têm um mentor a quem ouvem.
Um exemplo de uma equipe de recursos: temos uma plataforma de serviço que permite comprar um serviço com um empreiteiro junto com as mercadorias. Por exemplo, comprei uma porta - você pode colocar imediatamente na cesta e na instalação, para que um mestre independente venha e faça de acordo com nosso padrão. Vamos verificar e pagar, dar uma garantia. Então, essa equipe fabrica um produto, para isso escreve soluções de TI e toma decisões de negócios, muda processos nas lojas. Concordo com os contratados. Lá - o proprietário do produto da empresa, o balconista das lojas, o arquiteto, desenvolvedores, analistas e o testador. Eles imediatamente usam nossa plataforma de API corporativa para entregar todos os dados e escrever um microsserviço. Essa abordagem - pessoas imediatamente operacionais e de negócios em conjunto com desenvolvedores e uma pequena equipe - permite criar rapidamente um produto. Mas acho que é melhor que eles mesmos mais tarde lhe digam como fica por dentro.
Inicialmente, não queríamos fazer testadores separados: havia uma tendência de o desenvolvedor seguir a metodologia TDD ou testar seu código até o fim. De fato, não foi muito eficaz. No começo, tudo correu bem: escreveu - você responde. Você precisa de testes para que seu aplicativo funcione corretamente. Porém, quanto mais tarefas e aplicativos se tornavam, mais difícil era. Algumas aplicações desapareceram, outras foram para o prod e não foram alteradas por meses. Tornou-se difícil escrever testes, mantê-los e assim por diante. Os analistas de equipe mudaram. Recentemente, eles concordaram que estavam errados: são necessários testadores. Mas os desenvolvedores não param de escrever testes e - às vezes - fazem TDD. Percebemos por nós mesmos que os testes que verificam a funcionalidade (o aplicativo funciona corretamente) e os testes que verificam se o aplicativo funciona em situações problemáticas devem ser realizados por pessoas diferentes. E, para o segundo, são necessários testadores, porque cobrem possíveis casos estranhos, não apenas com testes de unidade.
Agora, existem 60 desenvolvedores puros - back, front, full stacks. Existem também analistas, testadores e suporte. E mais sete devops adicionais. Mas ainda assim, 200 pessoas planejadas do título não são recrutadas, por isso estamos procurando novas pessoas, porque o campo de trabalho é enorme. Existem vagas no
meu círculo , se isso. Ou seja, do desenvolvimento, agora temos 74 em cerca de 200.
InnerSource
Dado que temos muitas equipes independentes apenas na Rússia, e ainda existem equipes que viram algo semelhante em muitos outros países, estamos nos movendo na direção da
fonte de
origem . Isso é muito semelhante ao código aberto dentro de um grupo limitado de pessoas.
Dentro do grupo ADEO de todas as divisões de países, todo o código está no github da nuvem. O projeto é elaborado de acordo com regras uniformes de design. Não há restrições de estilo, tecnologia e ferramentas. Quando você tem código-fonte aberto e regras de design claras, qualquer desenvolvedor da pilha pode contribuir. Para copiá-lo no código, você precisa ler o dock, clonar o repositório, fazer uma edição, enviar uma solicitação de recebimento.
Atualmente, Brasil, Rússia e França estão usando muito ativamente essa base comum.
Agora, estamos tentando transferir o código inteiro dos contratados (e temos muitos deles em direções diferentes) para o InnerSource. Na análise, criamos um mapa em dois eixos: a complexidade técnica da transferência para o modo do círculo interno em um eixo e o segundo eixo, quanto a transferência para o círculo interno geralmente é útil. Se o código for único e necessário apenas em um lugar - talvez você nem precise tocá-lo. Mas se muitas equipes usam este site - é definitivamente necessário.
Tudo isso geralmente melhora a cultura de desenvolvimento. E acelera a velocidade de várias equipes, porque você pode escrever uma solicitação de mesclagem para qualquer recurso necessário. Será apropriado pela equipe do proprietário e testado por quem é o colaborador. Uma das condições importantes é a disponibilidade de autotestes e descrições de qualquer código no repositório.
Mais algumas nuances
Quando eles começaram, não havia nada. Paralelamente aos desenvolvedores, eles recrutaram devops. Agora, os devobservices são fornecidos como um serviço (para quem precisa) ou a equipe de produto tem suas próprias operações, que já determinam o que e como.
A montagem é feita em Jenkins, o código é executado no Sonar (mais precisamente, já o SonarQube). Sonar falhou - sem liberação. Os testadores escrevem autotestes, proprietários de códigos - testes funcionais. O banco de dados é fornecido como um serviço pelos engenheiros de infraestrutura. O teste de carga completo é realizado em casos raros, uma vez que a estrutura da base de testes e a principal são diferentes: no pré-produto, temos dados caóticos e não dados reais anonimizados (esta é uma das etapas no futuro), portanto, é necessário rolar suavemente e nem todos de uma vez.
Em breve, devemos ir ao Kubernetes (e alguns dos novos produtos, como o
mercado já
estão lá inicialmente), assim que descobrirmos o plano de transição e concordarmos com todos os detalhes da infraestrutura.
Meus colegas e eu continuaremos falando sobre como é organizada parte do trabalho, porque em quase todos os lugares você pode continuar infinitamente. Bem, você pode acompanhar o nosso reality show (porque tudo está sendo construído e mudando rapidamente) e apostar se estragamos tudo ou não.