|
Audio
|
Assim como DevOps, Continuous Integration (CI) se trata de cultura e processo e você precisa implementar isso rapidamente.
Em linhas gerais trata-se de uma prática do time de desenvolvimento em centralizar todos os códigos em um repositório.
Em seguida, são consideradas várias ações e possibilidades. A automatização de processos, execução de testes, padronização, notificações, execução de rotinas e a publicação das atualizações no ambiente desejado, são alguns exemplos.
Neste artigo a ideia é abordar o conceito e algumas possibilidades. Em outra oportunidade falaremos de ferramentas para a implementação dessa cultura.
Continuous Integration é comumente conhecida também como CI, as letras iniciais, mas também encontramos literaturas abordando o assunto como Continuous Development (CD).
Repositório e ambientes
O ponto de partida para a implementação desse processo é centralizar todos os arquivos do projeto em repositórios para o versionamento.
Além de ser necessário para usufruir das possibilidades, é requerido também para o trabalho em equipe. Além de backup e alternativa para voltar ao tempo dos códigos (como uma máquina tempo) e guardar cada versão já publicada e as que estão em desenvolvimento.
Considerando o GIT como repositório, podemos atrelar branches para cada ambiente de desenvolvimento em uso.
Considerando um cenário com três ambientes, Desenvolvimento, Homologação e Produção, poderíamos considerar, por exemplo, os branches development, homolog e master, respectivamente, para associar o repositório aos seus respectivos ambientes.
Automatização de processos
Com o alinhamento entre repositórios e ambientes de desenvolvimento, podemos ter a mágica da publicação automática dos arquivos.
Ou seja, sempre quando algum arquivo for enviado, através de commits, para um determinado branch teríamos um processo atrelado a isso para enviar os arquivos para o respectivo ambiente de desenvolvimento.
Nada de finalizar a programação e precisar conectar em programas de FTP para o envio de arquivos. E sinceramente, bom desenvolvedor não gosta de FTP, é retrógado, lento e nada funcional.
O processo de publicação automática dos arquivos em ambientes com um processo de CI abre as portas para uma infinita possibilidade de automatização. A mais simples deles é a publicação automática dos arquivos no servidor.
Testes e a padronização de desenvolvimento
Com vários desenvolvedores trabalhando no mesmo projeto, é importante seguir um padrão de desenvolvimento. Todos do mesmo time precisam falar a mesma língua.
É possível configurar testes para serem executados antes dos códigos serem enviados para os branchs no GIT. Com isso, somente se o código estiver no padrão seria aceito.
Assim, o desenvolvedor seria alertado que há algo de ser errado ou o padrão não foi seguido. Logo, nada como uma boa xícara de café para te ajudar a padronizar e concluir a demanda.
Execução de rotinas
Os arquivos quando publicados no servidor, precisam passar por rotinas para garantir segurança e performance, por exemplo.
Pastas e arquivos precisam seguir diferentes permissões. Essas definições podem ser feitas automaticamente com a execução de uma rotina para esse fim após a publicação dos arquivos no servidor.
Arquivos JavaScript e CSS também podem ser compactados para melhor performance e tempo de carregamento.
Quando você tem definido os processos necessários a serem feitos após a publicação dos arquivos no servidor, é possível automatizar essas rotinas com a cultura de Continuous Delivery.
Comunicação em Continuous Integration
Como estamos falando de processos, rotinas e automatizações, precisamos considerar também uma comunicação para melhor fluidez do processo.
A cada publicação de arquivos nos repositórios ou no servidor, é possível notificar o time envolvido através de e-mail ou canais no Slack. Seja de forma positiva para informar o sucesso, ou reportar falhas.
Dessa forma, a automação conversa com os envolvidos, notifica, alerta e todos ficam em sintonia dos acontecimentos.
Backup e reversão
Com todos os arquivos centralizados em repositórios, além de todos os benefícios aqui citados, acabamos realizando backups e uma verdade máquina do tempo do projeto e podemos voltar em qual tempo gostaríamos.
Uma cultura de Continuous Integration também nos permite ser muito ágil com o processo de reversão de publicação no servidor.
Imagina que algum bug tenha acontecido, ou que por algum outro motivo a publicação precisa ser desfeita (e rápido), por que é momento de pico e temos grande audiência.
Basta voltarmos ao tempo anterior da publicação e deixar o processo realizar uma nova publicação. Assim, resolvemos o problema de forma ágil, efetiva e voltamos a programação para análises e correções.
Imagina ter que realizar esse processo com FTP?
Conclusão
A cultura de Continuous Integration emprega inúmeros benefícios e possibilidades. Os ganhos são realmente incríveis.
Com essa cultura empregada, dedicaremos mais tempo a criatividade e o foco na produção do projeto. O restante será responsabilidades de robôs.
O cenário de Continuous Integration bem aplicado realizará incríveis ações de Continuous Delivery.
Do meu ponto de vista não ficou claro pq para o bom programador FTP não presta. Gostaria de entender melhor como é o ambiente de trabalho, isso não ficou claro, ferramentas e metodologias de desenvolvimento.
FTP é lento e arcaico.
Através de Continuous Integration o workflow fica mais organizado, flexível e ágil.
Isso é uma evolução, mas a base de tudo é usar repositório de códigos, como o GIT.