A experiência de desenvolvimento acumulada em projetos grandes e complexos está incorporada em ferramentas e práticas de engenharia úteis, que precisam enriquecer os processos de desenvolvimento, repensando tudo de novo. Foi o reconhecimento do valor da experiência adquirida como um artefato, o desejo de desenvolver, que nos levou a entender a necessidade de implementar ferramentas e práticas nos processos atuais. E lançamos uma revisão radical das abordagens para projetar soluções e para o processo de desenvolvimento como um todo. Não faz sentido descrever as limitações e deficiências típicas da abordagem "clássica" ao desenvolvimento de equipes no mundo 1C. Muito já foi dito sobre esse assunto. Descreverei apenas os padrões que nos permitiram reduzir essas deficiências e quase não assustá-las.
Então, se familiarize, o
suporte de desenvolvimento integrado!Princípios gerais de arquitetura
Ao projetar a arquitetura do estande, tentamos cobrir todo o ciclo de vida das soluções implementadas nos projetos, implementar a experiência adquirida, padronizar processos e automatizar a rotina. Ao mesmo tempo, era necessário estabelecer o potencial de desenvolvimento, manter a capacidade de dimensionar e máxima simplicidade, em termos de serviço, desenvolvimento e experiência do usuário. Ferramentas e técnicas que se mostraram eficazes na prática devem ser adicionadas ao processo. E todo inútil, interferindo no trabalho, deve ser removido.
O processo
O ciclo de vida de qualquer solução permanece praticamente inalterado, dependendo da escala e complexidade do projeto. Inclui: análise, projeto, desenvolvimento, teste, implementação, manutenção, desativação. Para obter a máxima eficiência, cada um desses processos deve ser verificado e coordenado com os processos anteriores e subseqüentes, combinados em um tipo de transportador automatizado, que pode ser replicado para um número ilimitado de projetos. A tarefa foi resolvida com a implementação do sistema na forma de microsserviços conectados por meio de APIs exportadas em contêineres isolados, que podem ser implantados no serviço de nuvem e na rede local da empresa.
É assim que nossa pilha de implementação do processo se parece:
Tentamos minimizar o uso de serviços pagos com código fonte fechado, o que afetou positivamente o custo de propriedade. Quase todos os serviços são de código aberto e são executados no Linux.
O processo foi projetado para tirar o máximo proveito de cada membro da equipe de desenvolvimento, e a padronização e a automação eliminam complexidade e rotina desnecessárias.
Design (Application Design Services)
Um dos estágios mais significativos no início de um projeto é o design de uma solução futura com base na análise de requisitos. A principal tarefa é descrever a arquitetura da solução futura da maneira mais clara possível, sem ambiguidade e rapidez, em termos compreensíveis para o desenvolvedor / engenheiro e o consultor. Descreva metadados, algoritmos de processos de negócios implementados. Ao mesmo tempo, eu queria maximizar o uso de modelos prontos que podem ser rapidamente adaptados a condições específicas que podem ser adaptadas aos dados de entrada e obter a documentação do projeto na saída.
Implementamos a configuração “1C: DSS” como uma interface única para o design de soluções aplicadas, reformulamos significativamente o conceito de descrição de processos e funções de negócios, bem como o design de TP (FDR). Eles também automatizaram os processos de geração de documentação por meio da integração com a funcionalidade 1C: DO e os microsserviços para gerar documentos no formato docx.
"1C: DPR". Editando informações do projeto:
"1C: DPR". Relatório de processo:
"1C: DPR". Editando metadados do objeto:
"1C: DPR". Editando um diagrama de processo de negócios:
A propósito, podemos visualizar o relacionamento entre processos e objetos de negócios no sistema, criar uma lista de melhorias com base nos requisitos registrados e obter documentação do projeto automaticamente, o que simplifica o processo de gerenciamento de mudanças. Portanto, planeje o processo de desenvolvimento em detalhes, veja a complexidade, a conexão das tarefas e determine com mais precisão o tempo e o procedimento para sua implementação.
Obviamente, não se pode dizer que o processo de design mudou drasticamente, mas a unificação das abordagens organizacionais e a automação de muitas funções já estão contribuindo para a qualidade dos projetos.
Desenvolvimento (Serviços de Integração Contínua, Inspeção e Teste)
Tentamos nos concentrar na possibilidade de um controle de qualidade abrangente, contínuo e automatizado do código desenvolvido, a fim de garantir a conformidade com o padrão estabelecido no CROC. Além disso, mesmo se envolvermos equipes de desenvolvimento de terceiros, cujos métodos, ferramentas e padrões de desenvolvimento podem diferir significativamente daqueles adotados por nós.
No estande, cada confirmação de desenvolvedor inicia automaticamente o procedimento para analisar a configuração no diretório e na estrutura de arquivos por meio do serviço Gitsync. As alterações resultantes são indexadas e colocadas no repositório Git. No nosso caso, este é o serviço Gitlab. A mensagem de confirmação é gerada automaticamente a partir do texto do comentário inserido quando as alterações foram publicadas no repositório de configuração, e o autor da confirmação no sistema de controle de versão é mapeado para o usuário do repositório de configuração. Durante a análise do texto do comentário, podemos obter informações sobre a tarefa de desenvolvimento e custos de mão-de-obra, transmiti-las ao sistema de rastreamento de tarefas, por exemplo, Jira. Isso fornece uma imagem abrangente do histórico de desenvolvimento. Por exemplo, podemos encontrar o autor por uma linha de código, e comentários inteligentes sobre confirmações permitem controlar automaticamente o status das tarefas e avaliar o código em relação às tarefas diretamente nas próprias tarefas.
Gitlab Agora é possível comentar qualquer linha do código colocado pelo commit:
Gitlab Realize a "Revisão de código" com destaque de sintaxe:
Gitlab Obtenha uma imagem clara das alterações de código no novo commit:
Após cada confirmação, o procedimento para inspeção de código estático pelo serviço SonarQube é iniciado automaticamente no repositório. O código de confirmação do BSL é verificado quanto à conformidade com um conjunto de regras (perfil de qualidade) que descreve o padrão de desenvolvimento do código. O procedimento é realizado tanto para o código da configuração que está sendo desenvolvida quanto para mecanismos externos: extensões, relatórios e processos externos e, em princípio, qualquer outro código de projeto, mesmo em outros idiomas.
SonarQube:
Cada verificação atualiza as informações das métricas de qualidade da base de código rastreada, como:
- dívida técnica - trabalho total necessário para corrigir erros identificados;
- limiar de qualidade - os indicadores máximos admissíveis de erros, vulnerabilidades e outras deficiências do código, ao atingir o qual a liberação do lançamento é considerada impossível;
- duplicação de código - o número de linhas de código que são repetidas várias vezes na estrutura da configuração desenvolvida;
- complexidade ciclomática e cognitiva - algoritmos com um grande número de ramificações que complicam o suporte e o refinamento do código.
As métricas coletadas como resultado da verificação fornecem uma representação visual do estado atual da base de código do projeto, permitem avaliar a qualidade, identificar riscos e corrigir erros rapidamente.
O perfil de qualidade pode ser expandido com seus próprios conjuntos de regras por meio do XPath, e também devido ao lançamento de novas regras como parte de sua própria implementação do plug-in 1C. Isso permite gerenciar de forma flexível os requisitos de qualidade, com base nas realidades de uma solução específica.
Início automatizado dos processos de análise de configuração, inspeção de código, teste automatizado etc. Lança o Serviço de Integração Contínua (Serviço Jenkins). O número e a natureza dessas linhas de montagem podem ser alterados de acordo com as especificidades de um projeto.
Apesar da complexidade relativa do processo descrito, todos os mecanismos de transporte que executam a rotina estão ocultos no serviço em nuvem. E o desenvolvedor lida com a interface familiar do configurador e também pode desenvolver suas habilidades usando ferramentas mais avançadas. Por exemplo, git, um repositório para mecanismos externos em conjunto com editores de código de terceiros e SonarLint, SourceTree etc.
No caso geral, o desenvolvedor conecta a base de informações ao serviço de armazenamento de configuração 1C, grava o código e o coloca nesse serviço, iniciando o processo oculto dele no estande. Se, como resultado da verificação de uma confirmação, forem identificadas deficiências no código, o desenvolvedor receberá uma notificação por email (ou mensagem do chatbot) com um link para a descrição do erro e recomendações para correção e avaliação temporária dos custos de mão-de-obra na interface de serviço do SonarQube. Após corrigir o erro, ocorre uma nova confirmação e o processo se repete, as tarefas editadas são fechadas automaticamente ... a dívida técnica diminui. Pela mesma lógica, um processo de teste automatizado é construído, em que cada confirmação inicia o lançamento da implantação do ambiente de teste, conecta os testes necessários a partir da biblioteca de testes. E após a execução, são agregadas informações sobre erros durante o teste, bem como sobre a cobertura de código com os testes.
É difícil superestimar o efeito da verificação abrangente e contínua do código, seguida pelo teste automatizado da funcionalidade desenvolvida. Isso permite que você se livre de conseqüências de longo alcance, torne os estágios de desenvolvimento transparentes e, juntamente com processos adequadamente construídos, avalie objetivamente as qualificações dos desenvolvedores, o que elimina os riscos de dependência dos contratados. Estimando os parâmetros da base de código atual, podemos identificar e mitigar rapidamente os riscos emergentes, corrigir falhas de projeto e responder às mudanças nos requisitos em tempo hábil.
A organização modular da arquitetura do estande permite incorporar novos módulos no processo, replicar a solução para o número necessário de projetos. Esquematicamente, fica assim:
Teste (serviço de teste contínuo)
Eu já falei sobre o serviço de teste contínuo, que é integrado ao pipeline do processo de desenvolvimento. No momento, uma execução de testes de fumaça e testes de unidade foi implementada no estande. A funcionalidade dos autotestes é implementada usando a estrutura xUnitFor1C.
O lançamento dos processos de teste, bem como a inspeção do código, está vinculado ao evento de confirmação no repositório do projeto. Para testes de unidade, significa desenvolver um teste em paralelo com o desenvolvimento da funcionalidade. Imediatamente antes de sua implementação, a configuração mais recente é implantada automaticamente na base de informações de teste preparada. Em seguida, o cliente é iniciado, que executa scripts de teste para a funcionalidade já implementada. A forte integração de serviços de teste automatizados com o plug-in BSL SonarQube permite calcular um parâmetro como cobertura de código com testes. O resultado da execução do teste é um relatório carregado no sistema de análise e visualização de teste do ReportPortal. Este serviço é um portal de relatórios no qual os dados das execuções de teste (estatísticas e resultados) são agregados, o treinamento básico do sistema sobre categorização de quedas é realizado e a determinação automática adicional das causas. Todos os parâmetros das execuções de teste estão disponíveis em uma interface web conveniente, com várias placas para gráficos, tabelas (widgets). Para expandir as funções do portal, você pode usar suas próprias extensões.
Um serviço de teste automatizado é outra etapa que reduz os riscos de entrar em um código de versão que quebra a funcionalidade implementada anteriormente ou trabalha com erros.
ReportPortal. Painel:
ReportPortal. Testes com falha:
ReportPortal. Tipos de defeitos:
ReportPortal. Editando tipos de defeitos:
Desenvolvimento
Avaliando os resultados do trabalho realizado, vemos que, do plano já implementado, quais idéias já estão funcionando com sucesso e que ainda precisam ser implementadas.
Dos planos para o futuro próximo, o desenvolvimento do estande é a criação de um portal de gerenciamento de serviços de estande. A interface da web do portal permitirá que você trabalhe com aplicativos para conectar projetos ao estande, com uma calculadora do custo dos serviços, com sua implantação automatizada mediante solicitação do projeto. Como resultado, o gerente pode obter imediatamente um cálculo do custo dos serviços selecionados e estimar os custos, determinar os desenvolvedores do projeto.
Planejamos integrar o portal a uma solução em nuvem para operar sistemas 1C. Isso ajudará a implantar rapidamente soluções padrão replicadas em conjunto com serviços de desenvolvimento implementados no estande para uma migração mais eficiente dos sistemas do cliente para a nuvem CROC.
Também planejamos integrar o portal de gerenciamento ao serviço de gerenciamento de configuração automatizado (implantação, configuração, exclusão). Isso reduzirá o tempo de implantação, simplificará a instalação e manutenção do sistema. E para aumentar o nível de segurança, apresentaremos um serviço de autenticação de passagem para todos os serviços do estande, a fim de usar a mesma conta em todos eles.
Se considerarmos todo o processo do ponto de vista do histórico de todo o ciclo de desenvolvimento da solução, o pipeline criado nos permitirá coletar e agregar um grande número de várias métricas, tanto por artefatos do projeto quanto por especialistas que participaram dele. Uma retrospectiva tão detalhada contribuirá para o acúmulo e reutilização de experiência na solução de problemas complexos, para formar equipes de desenvolvedores bem-sucedidos para um trabalho mais eficiente e coordenado.UPD A pedido dos comentários, adicione uma lista de produtos de código aberto que usamos, com links.