O desenvolvimento de software é uma atividade intelectual que exige conhecimento, disciplina e criatividade. Não é uma tarefa repetitiva, não é mecânica e nem pode ser automatizada ou executada por um robô (pelo meno por enquanto). E portanto é uma atividade que esta sujeita a falhas, pois nós todos somos passiveis a falhas.
Quando o desenvolvimento é realizado por uma equipe, multiplicamos exponencialmente o grau de complexidade e a dificuldade no desenvolvimento do software. Pois agora além das falhas individuais, acrescentamos falhas de comunicação, caos na organização do código fonte, falhas de integração, dentre os diversos problemas que podem ocorrer.
A importância de implantar um fluxo de trabalho para o desenvolvimento de software.
Para evitar esses problemas é muito importante que o desenvolvedor ou a equipe de desenvolvedores possua um processo bem definido de trabalho. Esse processo deverá servir como base de sustentação ao desenvolvimento do software. Prevendo possíveis falhas e diagnosticando problemas antes que o software seja entregue ao cliente.
Na Aelian nós criamos um Workflow que pode ser resumido em 3 processos:
1 – Ciclo de desenvolvimento.
2 – Integração Contínua.
3 – Deploy.
Cliclo de desenvolvimento
Nos baseamos no Github Flow para nosso ciclo de desenvolvimento, que ocorre da seguinte maneira:
1 – A cada nova feature, melhoria ou bugfix o primeiro passo do desenvolvedor é sempre criar uma branch derivada da branch master.
2 – O desenvolvedor então implementa os testes unitários necessários, codifica e refatora seu código.
3 – Ao concluir tarefas o desenvolvedor realiza seus commits de código.
4 – Antes de publicar o novo branch, o desenvolvedor realiza uma nova atualização da sua base de código para evitar ou resolver possíveis conflitos.
5 – Após testar, rever seu código e fazer o rebase do código atual. O desenvolvedor publica sua branch remotamente e gera um pull request.
E então o código segue para o processo de Integração Contínua.
Integração Contínua
Para esse processo nós utilizamos a ferramenta Jenkins para automatização e uma série de ferramentas disponíveis gratuitamente na internet, utilizadas ao longo de todo o processo. Quando o Jenkins identifica um novo pull request de um desenvolvedor ele dispara o que chamamos de Build (Construção). Que é um conjunto de rotinas de verificação do software:
1 – Realiza o checkout da branch que o desenvolvedor acabou de publicar. Em seguida faz o merge local com a branch master.
2 – Limpa arquivos e logs antigos e prepara o ambiente para uma nova série de verificações.
3 – Realiza a verificação de tamanho e complexidade do código fonte em PHP através da ferramenta PHPLOC.
4 – Varre o software em busca de códigos desnecessários, e qualquer indício de desorganização ou falta de boas práticas que possam gerar futuros bugs através da ferramenta PHP Mess Detector.
5 – Verifica se o código esta dentro dos padrões previamente estabelecidos pela equipe. Problemas como falta de identação, nomenclatura de classes, métodos e variáveis podem ser detectados através da ferramenta PHP CodeSniffer.
6 – Busca por copy/paste, ou seja, duplicação do código no software através do PHP Copy/Paste Detector.
7 – Roda todos os testes unitários automatizados através do framework PHP Unit.
8 – Gera os relatórios e logs dos resultados das verificações realizadas.
9 – Caso o código viole alguma das verificações realizadas a build é marcada como FAIL e o desenvolvedor recebe um e-mail com todos os relatórios e logs da construção para verificação e correções necessárias.
10 – Se o código passar por todas as verificações sem violar nenhuma regra de verificação a build é marcada como SUCCESS e é realizado o merge do Pull Request com a branch MASTER. Concluindo o processo o Jenkins cria uma TAG, isto é, uma marcação que determina a versão do software que esta apta para o processo de Deploy.
Deploy
O processo de deploy nada mais é que o processo de entrega do software. Basicamente é um shell script que executamos em nosso ambiente de produção. Esse script executa as seguintes operações:
1 – Baixa a nova TAG do software que acabou de ser gerada pelo nosso processo de Integração Contínua.
2 – Baixa as atualizações das dependências do software, caso possua.
3 – Organiza a estrutura de pastas e arquivos se necessário.
Não é minha pretensão dizer que esse fluxo é perfeito ou é o melhor a ser utilizado. A mensagem que gostaria de deixar com esse post é que o importante é que o desenvolvedor siga um processo. E de preferência adote a prática de inspecionar e adaptar esse processo continuamente. Eu acredito que dessa forma o desenvolvedor gradativamente e inevitavelmente irá atingir um alto nível de produtividade e qualidade no seu trabalho.
Deixar um comentário