Mão na massa – Integração contínua com FTP em hospedagem compartilhada

Dando continuidade ao post sobre integração contínua com FTP (Se não viu segue o link).

Vamos a como resolvi esse meu problema.

Não vou explicar sobre o Git, esse já tem sua documentação fácil.

Começando com o Bitbucket, ative o pipeline, em seu projeto Configurações > Pipelines > Settings (O Bitbucket ainda não fez toda a tradução)

Criei o arquivo bitbucket-pipelines.yml na raiz do projeto, ele é o responsável pela build. Um exemplo simples, apenas rodando o PHPUnit é esse:

Pronto, com isso a cada commit que for feito, o Bitbucket vai disparar a pipeline e com isso gerar o build, com isso vamos ter o seguinte resultado:

Com o processo de build e testes automatizado, podemos pensar no deploy. Para isso usei o DeployBot. Quando criamos o primeiro repositório, o DeployBot faz uma interface passo a passo, mas, como meu plano é o gratuito, só tenho um repositório e ele esta em uso. Vou mostrar as configurações, ai você pode ajustar 🙂

No primeiro passo, criamos o ambiente, no meu caso, apenas produção (no test no fear).

E suas configurações.

Com a configuração de deploy manual, eu preciso mandar fazer o deploy todas as vezes, se esse servidor fosse de QA, facilmente estaria no automático.

Depois de criar o ambiente, é necessário criar os servidores, essa parte é o simples apontamento para onde os arquivos de deploy devem ir.

Configuração de FTP.

No seu cPanel.

Agora que já sabe para onde vai, hora de ajustar as dependências

Outra coisa que podemos fazer aqui, é colocar arquivos com base no ambiente, isso ajuda nas configurações de banco de dados por exemplo.

Essa parte eu não consegui entender bem, mas, em meus testes, sem usar isso a próxima parte da problema…

Aqui ele simplesmente instancia o docker e executa “php -v”, só para saber a versão mesmo, sem segredo.
Essa é a parte da mágica, o DeployBot, só vai executar essa parte caso o composer.json seja alterado, isso é muito bom, pois não vai enviar a pasta vendor sem a necessidade

Agora é só partir para o deploy.

Quando você executa o deploy a primeira vez, ele vai enviar tudo (TUDO) e ficar mais ou menos assim.

Carregando as dependências.Enviando os arquivos.Quando precisar fazer outro deploy, vai enviar apenas a diferença.Aqui, você também pode ver o arquivo de configuração por ambiente foi enviado.

Agora é só curtir 🙂

Integração contínua com FTP em hospedagem compartilhada

Deploy via FTP hoje em dia é tipo o Batman, o herói que nós precisamos e não o que queremos.

Nos últimos dias, estou trabalhando em um projeto que não há orçamento disponível, basicamente, minha esposa mandou parar de gastar.

Junto com um amigo, tenho um plano de revenda de hospedagem compartilhada, esse aqui, vendemos esse serviço para outros amigos e por ai vai. Como não há orçamento para esse projeto, estou usando uma cota minha da revenda.

Sendo uma hospedagem compartilhada eu perco diversas coisas, uma delas é o acesso SSH, algumas até disponibilizam, mas a minha experiência com isso não foi das melhores.

Vamos ao ambiente. Como repositório de código eu deixo no Bitbucket, isso porque eu posso criar repositórios privados de graça. Com ele eu uso o serviço de pipeline, também de graça. No pipeline, posso montar da mesma forma como no Trevis CI, um arquivo de configurações e ele se vira para rodar os testes unitários, de aceitação e por ai vai.

O deploy, faço via FTP, sim é muito chato fazer isso, mas tem um cara que resolve esse problema para mim, novamente, DE GRAÇA, ele é o DeployBot, com ele, consigo rodar “composer install” em uma imagem docker e ele gerencia isso para mim, pega os arquivos criados na pasta vendor e encaminha para o servidor, conforme for alterado o composer.json ele vai enviar novamente essa pasta, caso contrário só vai enviar as alteraçõs que estão no commit, esse gerenciamento é o que possibilita o deploy via FTP ser aceitável.

Juntando tudo isso, eu consigo fazer meus deploys de forma fácil, não preciso deixar as dependências no projeto e o melhor, usar efetivamente um FTP, o DeployBot que se vire nisso.

Volto a falar, existem formas melhores de fazer isso, mas o deploy via FTP é uma realidade, vamos deixar isso pelo menos mais fácil.

Assim que terminar eu posto o mão na massa, explicando como eu fiz tudo.

 

[ATUALIZAÇÃO]

Link explicando como foi feito.

Automatizando o não automático

Aposto que você já ouviu várias pessoas falando sobre a automatização de tarefas no desenvolvimento de software e acredito que seu foco estava no Jenkins, Trevis CI e por ai vai. Depois de algum tempo trabalhando em um projeto que iniciei na empresa onde trabalho, percebi que os projetos open source tinham uma grande contribuição que ia além das ferramentas de CI.

Nos projetos que participei, notei que algumas das informações que eu precisei pedir para alguém, eu simplesmente não precisaria, essa informação poderia estar em algum lugar mais simples do que na mente de alguém, não falo em documentação em si, falo dos itens básicos para que alguém que não faz parte do seu dia a dia possa te ajudar no seu produto.

Imagine o seguinte. Você faz deploy todos os dias no ambiente de QA, ali você coloca diversas alterações de código, você garante que o código que esta ali funciona basicamente com duas coisas, testes manuais para validar aquele teste automatizado que acabou de fazer e testes automatizados, esses para garantir que não quebrou nada. Para “avançar” de ambiente, não há muita diferença, logo o maior trabalho de deploy automatizado esta em QA.

Agora, como resolver problemas de automatização com as coisas que você não precisa fazer todos os dias. Se não se faz todos os dias não precisa ser automatizado, simples, problema resolvido. Só tem um pequeno problema, sua vida não esta ficando mais fácil.

Como você resolve aquele problema de explicar para o cara novo como a banda toca? Um README.md já resolve a maior parte de seus problemas, um CONTIBUTION.md então, nem se fala. Olhe o README.md do Skeleton do ZF2, ele se explica.

Monte uma documentação pensando em alguém que chegou agora no seu time pode fazer um “hello word”, do contrário, toda a vez que uma nova pessoa chegar ela vai precisar falar com você. Ninguem chega alterando o core, simples assim, por conta disso, essa é a documentação que mais precisa ser visível.

Faça isso com um exemplo simples, formate seu computador (ou crie uma VM), você PRECISA conseguir subir seu projeto seguindo apenas a documentação do README.md e do CONTRIBUTION.md, se precisar ir no stack overflow já sabe seu próximo commit. Ou melhor ainda, use o cara novo, tudo o que ele tiver de fazer para rodar o projeto na máquina dele ele coloca na documentação.

Você não automatizou o processo da criação de uma nova máquina de desenvolvimento, mas você automatizou você, seu conhecimento agora esta em um arquivo de fácil leitura (eu acho), agora não é mais necessário chegar até você para iniciar o projeto, essa documentação já resolve o quick start.

Automatizar não é apenas para as tarefas de todo o dia e sim para tarefas repetitivas, sendo elas eventuais ou não. Toda a vez que você automatiza um processo, você reduz possíveis erros operacionais.