Como engenheiro de DevOps , com experiência em Operações, você deixou de criar e implantar servidores e software manualmente para criar scripts de instalação de software em seus servidores com BASH, PowerShell, Python etc. Depois de um tempo, você perceberia como é um script interessante e começa a explorar maneiras mais sofisticadas de automatizar a implantação .
Eventualmente, você teria escolhido um Chef, Puppet, Ansible ou outra ferramenta de gerenciamento de configuração para ajudar a gerenciar o estado de sua frota de sistemas. À medida que suas habilidades com a automação da implantação de aplicativos e o gerenciamento do sistema amadureceram, juntamente com suas ferramentas, você mudou mais recentemente para o domínio ' Infraestrutura como código ' e o usou para não apenas automatizar a implantação de software, mas também a infraestrutura e os ambientes necessários para conduzir o software durante a mudança da empresa para a nuvem.
Agora você está cozinhando com gás. Com o tempo, você foi apresentado aos benefícios do uso de ferramentas centradas no desenvolvedor, como controle de origem, para gerenciar os módulos, receitas e modelos que compõem seu arsenal de ferramentas de implantação e gerenciamento.
Quando você entrou na equipe do DevOps , foi exposto ao ciclo de vida de desenvolvimento de software e ao conceito de integração contínua . Cara, esses desenvolvedores estavam lançando mudanças rapidamente e, para acompanhar, você se viu trabalhando mais de perto com os desenvolvedores! Você sentiu a urgência colocada na equipe de desenvolvimento de mudar as coisas o tempo todo, o que contraria o antigo paradigma operacional de " se não está quebrado, não conserte ". Chega de se gabar do tempo de atividade do sistema, você está na infraestrutura descartável .
Você notou que a mudança para o DevOps era mais do que trabalhar com os devs , ou usando novas ferramentas e técnicas , mas houve uma nítida cultural mudança na equipe, que permeou através da organização em geral. Você estava trabalhando como uma equipe unida, com responsabilidades compartilhadas , ferramentas e objetivos compartilhados .
Você pegou suas habilidades na implantação automatizada e as massageou no pipeline " CICD ", orquestrado por um " servidor de integração contínua ", como Jenkins , Bamboo ou Code Pipeline . Agora, quando os desenvolvedores lançam um novo código, seus scripts, ferramentas e modelos sustentam novos ambientes sob demanda, acionam estruturas de teste para fazer suas tarefas e derrubam os ambientes de pré-produção depois que as luzes verdes acendem no lançamento, aderindo ao idéias de " entrega contínua ".
À medida que o novo código percorre os estágios do CICD, você, os desenvolvedores e a empresa ganham confiança de que a atualização não será interrompida quando lançada na produção. Há algum caminho a percorrer antes que a equipe chegue à " implantação contínua ", você ainda precisa se concentrar nos pontos mais delicados da automação do recurso de implantação azul / verde , e a decisão é principalmente de negócios. Por enquanto, você está satisfeito com o fato de o número de chamadas às três da manhã ter diminuído e os setes-1 e set-2 diminuírem.
Mesmo que você receba um sev-1, não aguenta mais a noite toda com os gerentes respirando pelas suas costas - você pode facilmente liberar a versão anterior através do pipeline do CICD e colocar o sistema on-line novamente em pouco tempo. Os negócios notaram que a estabilidade dos sistemas de TI melhorou, apesar da velocidade das mudanças .
Você se maravilha com a maneira como gerencia os recursos necessários para impulsionar o software em seus negócios, especialmente quando pensa em como costumava ser e na quantidade de sangue que você deixou para trás nos trilhos no datacenter ...
