Sim, existe vida
além do FTP
GUSTAVO PEREIRA
@ DARKMIRA TOUR PHP 2017
Precisamos falar sobre...
Ok, mas quem sou eu?
Gustavo Pereira
12 anos na área de TI
Bacharel em Ciências da Computação
Tecnólogo em Processamento de Dados
Zend Certified PHP Engineer 5.5
Desenvolvedor PL na MT4 Networks
http://www.mt4networks.com.br
Gosto pra caramba de
Comunidades
(e você também deveria)
O problema do
’publicar na mão’
Segurança
O problema do
’publicar na mão’
SegurançaMas aí eu
uso o SFTP
e...
O SFTP(*) pode te levar a
Falhar miseravelmente
Estou 'subindo os arquivos em
produção', um a um e aí na hora
acontece algo que
foge ao nosso controle
Ou ainda o(a) colega de trabalho está
fazendo a mesma coisa...
... Com os mesmos arquivos.
Ah Gustavo, mas eu agora só uso o SCP
$ scp bolinha.tar.gz install@bolinha.com.br:~/bolinha20170523142023.tar.gz
 OK, mas se ocorre um bug em produção
e você precisa de um rollback, o que faz?
 OK, mas se você descompacta num dir
errado?
 OK, mas se seu cliente está utilizando a
aplicação naquele momento?
Muda o método,
Mas continuam os erros!
E a tentação de
alterar arquivos em
produção?
(é coisa rápida)
E seu controle de versão, como é
usado?
O time inteiro comitando só na
master?
Deploy sem muito controle
=
RETRABALHO
Pense num
mundo de possibilidades
que uma estratégia de
deploy pode te oferecer
• Rollbacks FTW
• One-time setup
• Controle do que está
sendo publicado
• ”builds” e quem sabe
um CI, hein hein?
O ”dia do deploy” não será mais
aquela data tão temida
Automação de tarefas ’comuns’
namespace :puma do
desc ’Garantindo que o dir. images seja acessivel pelo nginx'
task :make_dirs do on roles(:app) do
execute ”chown –R install:www-data /var/www/images"
execute ” composer self-update ”
end
end
Isole os problemas
Um commit
deve sempre
resolver um
problema
apenas!
Menos risco de perder o fds
num deploy desastrado
Ok, mas como começar a
mudar?
(aqui vão algumas dicas!)
Uso efetivo /
correto do
(insira aqui
seu VCS
preferido)
Configure seu ambiente de
”homologação” para ser
idêntico ao de produção
(e o de dev também se possível)
Seu código
precisa passar
por uma bateria
de testes
automatizados
Suas alterações
disponíveis
e visíveis
a todos da equipe
Dividir para conquistar:
publique as pequenas
alterações
Proponha uma
evolução de acordo
com o que você
pode gastar
E com o $$$ que
seu cliente está
disposto a pagar
Proponha uma
estratégia/stack
de deploy clara
Snapshot = um ’pacote’
que representa o sistema
como um todo naquele
momento
Considere a possibilidade de pensar numa
metodologia Ágil de desenvolvimento
https://github.com/mislav/git-deploy
Setup bem simples
https://github.com/mislav/git-deploy
Uma regra
para cada ambiente
Uma regra para cada
ambiente
E na hora do deploy...
$ cap production deploy
$ cap staging deploy
$ cap production deploy:rollback
Mas eu gostaria de...
https://stackshare.io/
Concluindo:
Existe uma infinidade de
ferramentas...
Mas já podemos pensar em
Continuous Integration
Continuous Integration is a software development practice where
members of a team integrate their work frequently, usually each
person integrates at least daily - leading to multiple integrations per
day.
Each integration is verified by an automated build to detect
integration errors as quickly as possible. Many teams find that this
approach leads to significantly reduced integration problems and
allows a team to develop cohesive software more rapidly and quit
using FileZilla or ’solo SCP’. (Martin Fowler)
http://bit.ly/checklist-cd
https://codeship.com/continuo
us-integration-essentials
https://chrisshayan.atlassian.net/wiki/display/my/2013/07/23/Continuous+Delivery+Matrix?ut
m_source=Codeship&utm_medium=CI-Guide
Perguntas?
Obrigado!
@gustavosteam
gustavoper@gmail.com
https://br.linkedin.com/in/gustavoperphp

Sim, existe vida além do FTP!