DevOps - Tempo é dinheiro!

Você acredita que tempo é dinheiro como eu?  Essa antiga expressão me parece que foi perfeitamente criada para o mundo de DevOps.

Vou mostrar alguns exemplos que permitem economizar muito tempo, e que poderão permitir que aqueles projetos bacanas mas com baixa prioridade que ficam sempre aguardando que aquele determinado recurso tenha tempo comecem a ser executados.

Atualmente para desenvolvermos algum software, temos muitos ambientes que precisamos manter atualizados (Dev, Teste Integrado, Homolog, Produção.... ). Normalmente os desenvolvimentos ocorrem em DEV e os developers são os responsáveis por cuidar desse ambiente. Mas a partir dai, outras áreas precisam utilizar esforços para a publicação de novos deploys.

Os developers criam seus pacotes e de alguma forma abrem uma solicitação para o pessoal de Database, Infraestrutura, Governança e similares para que façam a publicação.

Database irá verificar cada script SQL para saber se possui código válido e se está dentro da política de segurança da empresa, depois disso, manualmente irá executa-los. Normalmente os DBAs criaram formas de recuperar a base caso algum problema ocorra.

Infraestrutura seguirá passo a passo o roteiro de publicação (cópia de arquivos, exclusão de diretórios, backup, execução de arquivos bat, start de pool....), e ao fim pedirá ao desenvolvedor para que teste.

Governança fará o registro da solicitação e manterá as informações em histórico.

Esse cenário parece com algo que você ve no seu dia a dia?

Quanto tempo o DBA utiliza com publicações?

Alguma vez por um equivoco do processo manual, foi esquecido a cópia de um determinado arquivo e os developers precisaram “debugar” o ambiente para encontrar o problema?

Quanto tempo poderia ser liberado para o time de Governança se não precisassem registrar em sistema o resultado de cada um dos deploys solicitados?

 Tudo isso é possível com a automatização de publicação.

Os developers criam seus pacotes, e através de uma ferramenta web, executam o deploy.

Os scripts SQL serão executados sequencialmente, passando por todas as verificações necessárias (Comandos inválidos, script em branco, servidor adequado...). Ao fim da execução, pode se gravar logs e enviar e-mail para o solicitante. Pode se ainda ter um fluxo de rollback automático caso algum script possua erro.

O roteiro de infra será seguido integralmente, tendo a certeza que nenhum arquivo deixará de ser excluído e todos os passos serão logados. Um backup inicial poderá ser criado e em caso de necessidade um restore será chamado.

Já governança, terá todas as informações do que foi executado, por quem, quando, status da execução e não perderá tempo tendo que registrar essas informações.

Com isso, todos economizarão tempo e os recursos que hoje executam essas atividades poderão estar alocados a outros projetos.

Faz sentido?