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

Quarta Novembro 18 19:23:23 UTC 2015

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
>>>
>>
>>
>>
>> --
>> Luiz Armesto
>>
>
>
>
> --
> Luiz Armesto
>

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