O elo perdido na evolução do ciclo de vida do desenvolvimento de software.

Mikhail Levkovsky em HackerNoon.com Segue 10 de jul · 5 min ler Foto de Johannes Plenio em Unsplash

A maneira como desenvolvemos, testamos e implantamos software tem avançado nos trancos e barrancos nos últimos 10 anos. Por razões de brevidade, e para não dar aos desenvolvedores da velha escola terríveis flashbacks de código em cartões perfurados , a linha do tempo que estou discutindo será focada nos últimos 11 anos (quando o Github foi ao vivo) e o único passo que perdemos quando trata de gerenciar e implantar seu software.

O processo como está hoje

A forma como entregamos o código no desenvolvimento de software moderno é mais ou menos a mesma na maioria dos lugares. Tudo se resume a um ciclo de vida de desenvolvimento de software (SDLC) e planejamento de produto / projeto e pode ser dividido nas seções a seguir.

Código

Você codifica colaborativamente usando ferramentas como Github, Bitbucket, Gitlab (ou para aqueles que se odeiam, SVN). Isso permite que vários desenvolvedores trabalhem em um único projeto em uníssono. Esta parte nós descemos. Depois de codificar você vai para a próxima etapa que está construindo.

Construir

Esta parte também é bloqueada com alguns processos muito bem definidos. Para garantir que os desenvolvedores possam criar e executar o código localmente, temos o docker. Para construir o código durante a implantação, usamos ferramentas como Jenkins, Circle CI, Travis …

Teste

Dependendo da sua pilha e dos objetivos de teste, suas ferramentas podem variar, mas isso se resume à mesma coisa. Você tem seus testes de unidade, testes de integração, testes de interface do usuário … Você pode usar ferramentas como os projetos Mockito para Java Spring; mocha, chai para projetos javascript / typescript; selênio para teste de interface do usuário e enquanto você usa essas ferramentas varia, a motivação de por que usamos essas ferramentas permanece a mesma. Todos esses testes podem e devem ser executados pelo processo de criação definido anteriormente.

Liberar e implantar

Depois de todo o seu trabalho duro, todos os seus testes passam, sua cobertura de teste está em 100% (estou certo ?) a parte divertida começa. Você começa a liberar e implantar seu código. Enquanto antes tínhamos literalmente “ inferno de integração ”, agora estamos em um bom lugar quando se trata de integrar diferentes componentes. Se você usa Kubernetes ou Rancher para o gerenciamento de orquestração e contêineres e AWS ou GCP para sua infraestrutura para este artigo, não importa. O ponto é que seu código é ao vivo, os usuários estão usando e amando.

Imagem de https://hackernoon.com/delivery-pipelines-as-enabler-for-a-devops-culture-ebc45963f703

Operar e monitorar

Depois de liberar e implantar, você precisa ter certeza de que seus aplicativos estão íntegros, suportando a carga, recuperando quando estão inativos…

Se você está ampliando seus pods no Kubernetes, certificando-se de que seu aplicativo não está registrando erros no ELK ou apenas observando suas métricas de desempenho no NewRelic; você precisa garantir que seu código esteja ativo, funcionando e fazendo o que deveria.

Planejamento e Comunicação de Projetos

Não é apenas o software de codificação e entrega que já percorreu um longo caminho. As melhorias no planejamento e na comunicação do projeto também ajudaram todos os envolvidos a entregar melhores produtos. Passamos de planilhas rigorosas e gráficos de Gantt para uma maneira ágil de entregar produtos, desde manifestos de 100 páginas até ferramentas como Jira e Asana. A comunicação passou de intermináveis tópicos de e-mail (bem, ainda temos aqueles, infelizmente) para usar o Slack.

Tudo somado, a indústria de software tem se concentrado em como agregar mais valor, em um ritmo mais rápido, sem sacrificar a qualidade. MAS, ainda há um elo perdido nesta evolução.

A única grande peça que cola todas essas peças juntas é o gerenciamento de suas configurações. Durante cada etapa da maneira como as chaves da API, as configurações e o contexto de como você executa o código são alterados.

O elo perdido

Com todas essas ferramentas e processos em vigor, ainda estamos perdendo uma maneira adequada de gerenciar nossas configurações.

Quando você está desenvolvendo, você está usando seu ambiente local e tem um conjunto de configurações. Mesmo se você quiser apontar seu ambiente local para o controle de qualidade para alguns serviços externos, ainda está mudando o contexto de como seu código é executado.

Quando você está construindo com o Jenkins, você quer rodar em um ambiente de teste ou de simulação (não queira executar os testes do e2e nos seus servidores de produção). Quando você libera seu código para produção, você precisa ter as chaves de API corretas nos lugares certos. Você não quer promover acidentalmente suas chaves Stripe de teste em seu ambiente de produção ou esquecê-las todas juntas.

Embora as configurações sejam necessárias literalmente em cada etapa do SDLC, não há um estágio definido para isso e, portanto, infelizmente, ele foi amplamente ignorado. Isso resultou em uma ampla variedade de soluções em toda a indústria de software. Isso causa grandes interrupções (olhando para você, Netflix ), violações de segurança (olhando para você Equifax ) ou uma tonelada de tempo perdida tentando descobrir por que toda a sua pilha de tecnologia caiu (olhando para você todos os desenvolvedores de software, incluindo eu mesmo). Quando se trata de gerenciamento de configuração, é extremamente difícil integrar e integrar membros da equipe com segurança, compartilhá-los em toda a organização de maneira segura e fazer a versão dos arquivos de configuração à medida que eles evoluem.

Todas as mudanças e evoluções anteriores mencionadas acima começaram caóticas e desorganizadas e foram padronizadas e acordadas pelo mundo do software.

A pilha atual de solução simplesmente não satisfaz as necessidades do SDLC atual.

Soluções como ansible-vault, git-encypt, Vault e Consul tentam abordar segurança e compartilhamento, mas errar o alvo completamente quando se trata de integração, off-boarding, controle de versão, release tracking….

É hora de evoluir e corrigir esse elo perdido. Gerenciamento de configuração, e quero dizer gerenciamento de configuração adequada é o último aspecto que está bloqueando o verdadeiro CI / CD.

No ConfigTree.co acreditamos que o futuro é colaborativo e estamos trabalhando para um espaço de Collaborative Configuration Management.

Não é mais necessário saber por que dois serviços não podem se conectar, não ter mais que embaralhar e alterar suas chaves prod no caso de alguém desistir, não mais procurar em logs nos logs por que você está falhando com um serviço externo.

Se você está cansado de lidar com arquivos mal administrados e sua própria maneira de lidar com as frustrações, me avise 🙂 Deixe um comentário abaixo ou me dê uma mensagem no twitter em @mlevkov ou @configtree .

Se você gostou do artigo, por favor, aperte ? para que outras pessoas possam apreciá-lo.