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

Quinta Novembro 26 22:27:05 UTC 2015

Webhook configurado (
https://github.com/okfn-brasil/gastos_abertos_website/settings/hooks)

O código está na pasta /home/gastosabertos/webhook do servidor e a url é
http://p.gastosabertos.org/_webhook/github/
Agora todo push na branch "preview" atualiza o http://p.gastosabertos.org
em questão de segundos

Importante, as dependências não são atualizadas automaticamente (para
reduzir ao máximo o intervalo entre o push e a atualização), só são feitos
os builds de arquivos estáticos e de conteúdo. Então temos que dar
manutenção em caso de adicionar novas dependência ou precisar atualizar a
versão de alguma.

Os virtualenvs são "ga_webhook" e "ga_preview"

[]'s

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

> Oi Luiz,
>
> me parece que o melhor mesmo é utilizaros branches separados, um
> pra preview e outro que representar a versão atual em produção. Daí
> seria fazer o webhook como falou. O único problema é que ainda não
> sei como tornar esse processo simples pros editores de conteúdo.
>
> Quanto aos domínios, coincidentemente eu tinha feito isso pouco antes
> de ler seu email. Precisamos apenas redirecionar o
> http://demo.gastosabertos.org
> pro novo domínio api.gastosabertos.org. Mas o api.gastosabertos.org
> já está funcionando.
>
> E quanto ao preview, eu resolvi usar um shortcut, p.gastosaberto.org,
> ao invés de uma palavra mais longa.
>
> Abs,
> Edgar
>
>
> On 19/11/2015 18:44, Luiz Armesto wrote:
>
>> É 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 [3]
>>
>> 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 [1], 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 [2] [1]
>>>
>>> --
>>>
>>> Luiz Armesto
>>>
>>> --
>>>
>>> Luiz Armesto
>>>
>>> --
>>>
>>> Luiz Armesto
>>>
>>> Links:
>>> ------
>>> [1] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev [2]
>>>
>>> _______________________________________________
>>> Gastosabertos-dev mailing list
>>> Gastosabertos-dev em lists.okfn.org
>>> https://lists.okfn.org/mailman/listinfo/gastosabertos-dev [2]
>>>
>>
>>  _______________________________________________
>>  Gastosabertos-dev mailing list
>>  Gastosabertos-dev em lists.okfn.org
>>  https://lists.okfn.org/mailman/listinfo/gastosabertos-dev [2]
>>
>> --
>>
>> Luiz Armesto
>>
>>
>> Links:
>> ------
>> [1] http://preview.gastosabertos.org
>> [2] https://lists.okfn.org/mailman/listinfo/gastosabertos-dev
>> [3] https://circleci.com/docs/configuration#tags
>>
>> _______________________________________________
>> 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/20151126/10cf7e4f/attachment-0003.html>