[Gastosabertos-dev] Deploy de atualização no site e no blog

Quinta Novembro 19 17:44:42 UTC 2015

É uma boa.

Pensei, para ser realmente rápido, fazer assim:

Criamos um webhook do github no nosso servidor que quando recebe o evento
"push", dá um "pull" no repositório, roda o "fab build" localmente (sem
rodar testes) e copia o conteúdo da pasta "build" para a pasta que estiver
sendo servida pelo apache/nginx (não lembro qual estamos usando) no
subdomínio "preview". Assim a cada alteração o preview deve ser atualizado
em questão de poucos segundos.

Daí para produção continua com o circleci, do jeito que está.

A única dúvida é sobre como determinar quando a alteração vai para
produção:
Usaremos dois branches separados, uma para homologação, que atualiza o
preview automaticamente, e um para produção, que dispara o circleci. Para
mandar para produção fazemos merge do de homologação no de produção.
Ou usamos tags para determinar qual commit irá para produção. As mudanças
simples (alteração de texto, publicação de post, pequenas correções) são
feitas no master mesmo, atualizando automaticamente o preview mas não
disparando o circleci para deploy de produção. Para mandar para produção
taggeamos o commit seguindo um determinado padrão de nome, fazendo o
circleci disparar o deploy para a tag (e não mais para o push) e assim
atualizar a produção [0].

Qual acham melhor?

Edgar, quando for configurar o subdominio "preview", eu gostaria que também
já deixasse configurados os subdomínios "api", para migrarmos a api do
"demo" para ele, "admin", para colocarmos o que for necessário para
facilitar a administração interna do projeto (monitoramento de serviço,
logs, webhook) e "status", para informações sobre o estado dos serviços (se
tivermos problema na api, se precisarmos interromper temporariamente algo
para manutenção, avisamos lá, pode ser a principio só uma página estática
alimentada manualmente mesmo).

[0] https://circleci.com/docs/configuration#tags

2015-11-19 12:17 GMT-02:00 Edgar Zanella Alvarenga <e em vaz.io>:

> Maravilha Luiz! Reduzir pela metade já é um grande avanço. O que acho que
> vai
> ser importante é pensarmos numa versão do site pré publicação, num novo
> domínio
> http://preview.gastosabertos.org, onde a atualização quando apenas
> modificação
> de markdown ou adição de novos posts seria automática. Deixaríamos apenas
> um
> clone da última versão estável do repositório gastos_abertos_website,
> daríamos
> git pull de novas modificações e finalmente fab build e deploy, o que acha?
>
> Abraço,
> Edgar
>
>
> On 18/11/2015 20:23, Luiz Armesto wrote:
>
>> Diminui o tempo de deploy de ~5:00 para ~2:30
>>
>> Acho que dá para diminuir ainda mais juntando todos os arquivos num
>> .tar e mandar o pacote todo para o servidor no lugar de mandar arquivo
>> por arquivo.
>>
>> Os primeiros ~00:40 são gastos na preparação da vm, então o que
>> conseguimos ainda dar alguma otimizada é nos ~1:50 dos nossos
>> comandos. Qual é a demora aceitável para o deploy?
>>
>> []'s
>>
>> 2015-11-18 15:39 GMT-02:00 Luiz Armesto <luiz.armesto em gmail.com>:
>>
>> Acabei de ver na documentação do circleci que é possível definir
>>> quais diretórios quer que sejam cacheado, aí sim.
>>>
>>> Vou fazer uns testes.
>>>
>>> 2015-11-18 15:27 GMT-02:00 Luiz Armesto <luiz.armesto em gmail.com>:
>>>
>>> Tem 2 grandes pontos de consumo de tempo no processo de deploy
>>> automático que podemos atacar
>>>
>>>  * instalação das deps de frontend (npm e bower)
>>>  * Instalação de deps de backend (pip)
>>>
>>> O segundo está sendo feito, aparentemente, de modo desnecessário.
>>> Se formos ver no log do circleci há uma seção "pip install" muito
>>> rápida (00:01), que parece estar usando um cache para não precisar
>>> instalar sempre os pacotes. Depois na seção "$ fab build_all &&
>>> fab deploy" é criada uma nova virtualenv e instalados todos os
>>> pacotes python, agora sem cache. O ambiente do circleci já é
>>> isolado e já usa uma virtualenv automaticamente, então não
>>> precisamos criar nossa propria virtualenv e reinstalar tudo. Isso
>>> já deve economizar cerca de um minuto ou mais.
>>>
>>> O ponto das deps frontend, a instalação dos pacotes do bower é
>>> necessária, pois é deles que são copiados os js para a pasta
>>> static no processo de build. Os pacotes do npm só são necessários
>>> para rodar os testes, se não me falha a memória. Então temos duas
>>> alternativas, uma é fazer esse detector e só baixar as deps do npm
>>> e rodar os testes se for necessário. A outra é fazermos algum
>>> esquema de cache dos pacotes, seja incluindo as pastas
>>> "bower_components" e "node_modules" no controle de versão, seja
>>> salvando-as externamente um um servidor nosso, e baixando-as e
>>> atualizando-as no processo de test e deploy.
>>>
>>> []'s
>>>
>>> 2015-11-18 15:03 GMT-02:00 Edgar Zanella Alvarenga <e em vaz.io>:
>>> *finalizando o email precoce :P*
>>>
>>> Atualmente estamos atualizando o site após um push no repositório
>>> gastosabertos_dev via circleci. O problema é que o processo do
>>> circleci é muito lento, ele cria uma máquina virtual, instala
>>> dependências nela, roda gulp, apt-get, faz testes, compila as
>>> páginas e envia os resultados depois de alguns minutos pro nosso
>>> servidor. O stack é sensato se pensarmos em só subir
>>> atualizações complexas após testes para termos certeza que nada
>>> ficará quebrado no site. Mas quando queremos apenas mudar um texto
>>> num dos arquivos de conteúdo markdown, ou publicar um novo post, o
>>> processo me parece muito lento.
>>>
>>> Como simplificar o processo? Criamos nos script de deploy um
>>> detector se as atualizações foram apenas nos arquivos markdown e
>>> nesse caso só geramos novamente as novas páginas?
>>>
>>> E.
>>>
>>> _______________________________________________
>>> Gastosabertos-dev mailing list
>>> Gastosabertos-dev em lists.okfn.org
>>> https://lists.okfn.org/mailman/listinfo/gastosabertos-dev [1]
>>>
>>> --
>>>
>>> Luiz Armesto
>>>
>>
>> --
>>
>> Luiz Armesto
>>
>> --
>>
>> Luiz Armesto
>>
>>
>> Links:
>> ------
>> [1] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
>>
>> _______________________________________________
>> Gastosabertos-dev mailing list
>> Gastosabertos-dev em lists.okfn.org
>> https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
>>
> _______________________________________________
> Gastosabertos-dev mailing list
> Gastosabertos-dev em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
>

-- 
Luiz Armesto
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/gastosabertos-dev/attachments/20151119/9b08b44f/attachment-0003.html>