Na NORBIT lidamos com soluções SRM . Hoje contaremos a vocês sobre um projeto especial para nossa equipe - o desenvolvimento da plataforma NBT BPMS. Não apenas criamos uma solução de negócios para o cliente, mas desenvolvemos nosso próprio produto do zero - tudo isso implica uma abordagem completamente diferente para design, desenvolvimento, gerenciamento de equipe, organização de processos de entrega de mudança e planejamento de liberação.
Em geral, o artigo não é apenas sobre o belo KDPV. Você também aprenderá:
- sobre a nossa experiência na concepção de arquitectura de microsserviços (escolha das ferramentas, abordagens à utilização dessas ferramentas, nomeadamente, abstração da sua utilização);
- sobre o desenvolvimento de um designer de objetos de negócios e implementação de um designer de processos de negócios na solução para garantir a abordagem do desenvolvimento de baixo código;
- sobre como organizamos o trabalho no projeto e salvamos os desenvolvedores de alguns aspectos rotineiros ou perturbadores ao trabalhar no sistema (interações abstratas entre serviços, geração automática de código, atmosfera de equipe);
- e sobre o que o meme nos ajudou em tempos difíceis.
A nossa divisão na empresa NORBIT dedica-se principalmente à automatização de processos de aprovisionamento, para os quais cria vários tipos de soluções na plataforma .Net.
O desenvolvimento de tais soluções começou com ASP.NET WebForms, então novas versões dessas soluções foram criadas com base no ASP.NET MVC. Além do desenvolvimento em .NET, tivemos e ainda temos outros projetos e soluções, mas mesmo assim o desenvolvimento em .NET representa cerca de 80% de todos os projetos do departamento.
As limitações de ambos ASP.NET WebForms e ASP.NET MVC sugerem que para as soluções funcionarem nessas plataformas, a implantação em um sistema operacional da família Windows Server foi necessária e, no lado do banco de dados (banco de dados), um volume de lógica foi implementado que não permitiu uma transição rápida e indolor em um DBMS diferente do MS SQL Server. Isso não previu quaisquer obstáculos e dificuldades antes do início da transição massiva para o software doméstico.
A partir de 2014-2015, o mercado de TI começou a se mover muito seriamente em direção à substituição de importações, e a questão de implantar nossos sistemas em sistemas operacionais e SGBDs que atendessem aos novos requisitos era bastante aguda. Na verdade, tornou-se a pergunta número 1que precisávamos resolver para que nossas soluções pudessem cobrir as necessidades de clientes em potencial a longo prazo.
Ao mesmo tempo, tendo fortes competências e uma equipe razoavelmente grande de desenvolvedores .NET, não parecia racional começar a desenvolver um novo kernel de plataforma cruzada diferente do .NET. O lançamento da plataforma .NET Core de código aberto foi muito bem-vindo para nós, inclusive por causa de sua compatibilidade com sistemas operacionais como Windows, Linux e macOS.
A questão número 2 , que precisávamos resolver, era que a maioria das soluções criadas anteriormente pressupunham uma programação obrigatória para adicionar atributos de objetos de negócios ou alterar processos de negócios no sistema.
Está associado a dois aspectos.
- ( ) - , , , . , , - , , -.
- Low-code development, , , « » - -.
E a questão número 3 , que enfrentamos há muitos anos, é a imperfeição das arquiteturas dos sistemas que estão sendo criados, o que não nos permite reescrever rapidamente alguma parte sem a necessidade de reescrever módulos individuais, ou cria um limite de entrada suficientemente alto para programadores, analistas e testadores ao se conectar a projetos.
Houve muito mais perguntas e problemas na entrada do projeto, que serão discutidos mais tarde. Mas esses três (substituição de importação e código aberto, código baixo, limite de entrada baixo e taxa de imersão rápida de novos membros da equipe) consideramos os principais que tivemos que resolver.
Projeto
Pensar sobre essas questões nos levou a perceber que precisamos de uma espécie de construtor com o qual os analistas possam "brincar" e projetar um sistema (objetos de negócios e processos de negócios) de acordo com as necessidades do cliente. Parece ousado, mas é muito mais interessante do que escrever outro sistema para um cliente. Na verdade, decidimos fazer nosso produto na forma de um construtor e desenvolvê-lo.
Definitivamente, não inventamos nada revolucionário e há muitos produtos semelhantes no mercado, mas era fundamental para nós resolvermos nossas questões acumuladas, especialmente porque, pelos motivos descritos anteriormente, era difícil para nós, para dizer o mínimo, seguir o caminho de refatorar sistemas existentes.
Na fase de projeto, tivemos que repensar o fato de que nem sempre sabemos de antemão quem é nosso cliente potencial, grande ou pequeno, exigente ou fiel, quais processos de negócio ele possui, que tipo de infraestrutura. Alguns dos requisitos para o futuro sistema começaram a surgir por conta própria: você precisa de escalonamento, precisa de plataforma cruzada, precisa de customização flexível e rápida de objetos de negócios / processos de negócios, uma interface, provavelmente um "vagão e um pequeno carrinho" de integrações. Tornou-se assustador, muito assustador.
Mas, como diz um dos líderes de nossa equipe, "O elefante precisa ser comido aos poucos, começando pelos pés." Nesta fase, nos propusemos duas tarefas: a escolha de uma arquitetura de microsserviço e a escolha de ferramentas. Sim, apenas microsserviço imediatamente (Martin Fowler recomenda MonolithFirst , mas decidimos desobedecê-lo), porque com monólitos há muito tempo estamos "você" e é hora de aceitar o desafio de seguir em frente. Mas, falando sério, a exigência de dimensionamento horizontal do sistema por si só é suficiente, em nossa opinião.
Escolha de arquitetura e ferramentas
Ao projetar a arquitetura, buscamos vários objetivos:
- abstração das ferramentas utilizadas para poder substituir uma ferramenta inadequada por outra a qualquer momento;
- ( , );
- , .
Como nossa equipe é especializada em tecnologias Microsoft, o .NET Core versão 2.1 foi escolhido como plataforma de implementação. No momento em que o desenvolvimento do nosso produto começou, esta versão era LTS (suporte de longo prazo), e para nós este era um critério importante, já que alguns sistemas operacionais domésticos (nos quais poderíamos potencialmente implantar o sistema) suportam apenas versões .NET Core LTS ...
Eles decidiram fazer Frontend em React + TypeScript, já que é fácil de aprender. Decidimos promover a abordagem de pilha completa de desenvolvedores.
Decidimos tornar a comunicação interserviços síncrona, porque nossas cadeias de chamadas deveriam ser curtas e a comunicação entre serviços ainda é abstraída. Um serviço chama outro serviço por meio de um proxy abstrato. E pode conter qualquer lógica. No nosso caso, trata-se de uma chamada para outro serviço via http via Service Discovery. Esse design nos permitiu, por um lado, simplificar a vida dos desenvolvedores (eles podem simplesmente usar a interface de serviço para chamá-lo, mas na verdade, no contêiner de serviço ASP.NET Core, a implementação registrada dessa interface é o mesmo Proxy) e, por outro - fornecer dimensionamento horizontal do sistema de forma automática, já que sempre perguntamos ao Service Discovery como chamar um serviço, e que, por sua vez, pode dar uma das instâncias em execução deste serviço.
Em algum momento, a estrutura do serviço tornou-se padrão, e fizemos extensões para o Visual Studio, que, quando um novo projeto é adicionado à solução, gera uma estrutura de projeto com uma implementação mínima do serviço, novamente, para que os desenvolvedores não tenham que fazer essa rotina. Além disso, fizemos vários scripts para iniciar todo o sistema com um leve movimento da mão (mais tarde pensamos na mesma rápida implantação de um orquestrador leve do desenvolvedor).
O processo de seleção também foi bastante interessante. Tivemos que decidir - que funcionalidade escreveríamos para nós mesmos e o que tiramos "fora da caixa" (falando sobre ferramentas existentes), mas, é claro, abstraindo toda a interação com isso, de modo que, se necessário, fosse possível substituir essa ferramenta ou biblioteca por outra implementação. Precisávamos das seguintes ferramentas: mecanismo de pesquisa, mecanismo de processo de negócios (BPMN Engine), protocolo de descoberta de serviço (Service Discovery), planejador. Os critérios eram diferentes: licenças, velocidade de trabalho, velocidade de imersão da equipe do projeto, etc. O resultado é a seguinte lista: Elasticsearch, Camunda, Consul, Hangfire.
Imediatamente eles estabeleceram suporte para pelo menos PostgreSQL e SQL Server, mas focaram principalmente em PostgreSQL e implantação em Linux. Software livre, você sabe. A esse respeito, aconteceu uma história curiosa. Estabelecemos o suporte para SQL Server nos estágios iniciais, mas não esperávamos que alguns de nossos clientes em potencial estivessem interessados em implantar no Windows + SQL Server, então adiamos o teste dessa configuração para mais tarde (afinal, sempre se sabe com antecedência qual ambiente o cliente possui?!) ... E então um dia, fazendo outro teste para um cliente em potencial, já estávamos prontos para implantar o AltLinux + PostgreSQL como de costume, mas de repente descobrimos que o cliente, no entanto, mudou de ideia e decidiu implantar no Windows + SQL Server, e temos dois dias para fazer tudo preparar. Felizmente, o código escrito há muito tempo e esquecido veio a calhar,que nos deu esse suporte com pequenas melhorias, e conseguimos preparar tudo a tempo, e o sistema funcionou como se nada tivesse acontecido (glória ao .NET Core).
Implementação de ideias de negócios
Abordamos a implementação com uma lista preparada de etapas de trabalho, e a mais importante delas foi conseguir MVP (produto mínimo viável) em um futuro próximo. Quase desde as primeiras iterações, começamos a trabalhar com ênfase em obter um protótipo o mais rápido possível com uma parte visual que possa ser demonstrada aos clientes (que foram nossos líderes no início) periodicamente. Essa abordagem, como esperado, contribuiu para repensar alguns dos conceitos anteriormente concebidos. Consegui captar várias contradições e combatê-las antecipadamente. Trata-se de projetar uma API da Web para comunicação de front-end e back-end.
Construtor de objeto de negócios
Já foi mencionado acima que uma das idéias principais do produto é a capacidade de criar uma estrutura de objetos de negócios por um usuário configurador. Na verdade, começamos com a implementação do construtor de objetos de negócios. As primeiras versões, é claro, eram mais conceituais, mas subsequentemente nos deram muito que pensar. Os objetos de negócios antes despretensiosos com alguns campos simples posteriormente evoluíram para unidades multifuncionais de vários níveis com uma ampla gama de todos os tipos de configurações. Aprendemos como configurar não apenas campos simples, mas também campos com uma escolha de diretórios hierárquicos, coleções relacionadas de objetos com filtragem e assim por diante.
O objeto de negócios gerado pelo mouse do configurador possui metadados suficientes para compilar registros pesquisáveis personalizados e diferentes formas de apresentação.
A questão de validar objetos de negócios também não nos poupou. Descobrimos rapidamente que a validação não pode deixar de ser acompanhada pela lógica de negócios que é necessária no estágio de preenchimento do objeto de negócios com dados. “Se“ campo 1 ”tem“ valor 1 ”, então“ campo 2 ”precisa ser escondido” ou “Campo 1 é a soma do campo 2 e campo 3” são apenas alguns dos exemplos mais simples que podem ser dados. Quanto tempo é curto, agora temos um mecanismo de evento no qual esse comportamento pode ser configurado. Os eventos também podem ser configurados com o mouse. Muitas opções já foram implementadas, incluindo cálculos complexos. Mas este é um assunto para outra conversa. Por favor, escreva nos comentários se você resolveu um problema semelhante, seria interessante trocar sentimentos.
Designer de Processo de Negócios
Como gostamos de repetir: "Quem precisa de objetos de negócios sem processos de negócios?"
resultados
Passou um ano e meio desde o início do projeto. A equipe aumentou dez vezes, o
A primeira coisa que parece mega-legal é o fato de que quanto mais funcionalidades criamos, mais ideias temos. Parece que não estamos indo do início do projeto para a sua conclusão, mas simplesmente do início e além - este é um aspecto importante. Depois de muitos anos apoiando soluções prontas (e isso acontece muitas vezes na vida de um especialista em TI), esse estado de coisas é muito motivador.
Segundomega sentimento é assistir a uma equipe tão motivada e estar por dentro. O processo de criação de um novo produto não é apenas uma sequência de tarefas e etapas. Essa é, antes de tudo, a atmosfera. A atmosfera do fato de você, muitas vezes, fazer coisas que nunca fez antes, embora tenha participado de dezenas de projetos. Cada membro da equipe respira e em algum momento percebe que deixou a zona de conforto após a primeira respiração. E a tarefa mais difícil e principal é tornar este ambiente fresco, confortável e interessante. Não podemos nos esconder de bugs, prazos, etc., mas a falta de um ambiente favorável em que todos nos encontramos pode ser muito mais destrutiva.
Procuramos dar atenção especial ao processo de desenvolvimento do nosso produto. Este processo não é estático. Ele passa por mudanças, se necessário, mas permite resolver seus problemas com conforto e ajudar seus colegas a fazê-lo.
PS É difícil descrever tudo em detalhes em um artigo, então acabou sendo mais uma visão geral. Esperamos realmente que você tenha encontrado algo interessante nele e teremos o maior prazer em responder às suas perguntas nos comentários ou descrever alguns aspectos do nosso sistema com mais detalhes em um artigo separado.