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

Quinta Novembro 19 19:26:45 UTC 2015

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