Código em desenvolvimento no Vagrant

leonardofl commented 9 years ago

Atualmente a receita Chef implanta o branch master do Radar.

Dado que o maior benefício do Vagrant é justamente a antecipação do uso de um ambiente production-like antes da produção, fica ruim ter que commitar o código no master pra testar no Vagrant.

Então um possível fluxo é: desenvolvedor commita código em uma branch alternativa, configura o Vagrant pra usar essa branch, e assim que ele conferir que sua funcionalidade tá OK ele faz o merge no master. O ruim é que isso parece ir contra a integração contínua, fazendo com que código possa passar muito tempo se se integrar com o master.

Outra possibilidade é fazer com que o Vagrant copie o código não-comittado ainda no ambiente do desenvolvedor. O ruim disso é que parece implicar em receitas Chef diferentes para o Vagrant (pega código do filesystem) e para a produção (pega código do git).

Outra possibilidade é ter uma outra branch oficial ("dev", por ex) na qual todos se integrem continuamente, e que a passagem para produção seja feita sob demanda. Aí o Vagrant pegaria do dev e a produção do master.

Decisão complicada, discussão e opiniões são bem vindas : )

gleicon commented 9 years ago

Você usa jenkins ou travis ? Se não, a alternativa poderia ser um githook. Este vagrantfile deve ser executado por alguem antes de ir para produção, tipo continuous integration manual ou QA ? Um commit no branch master já executa o deploy em produção ?

leonardofl commented 9 years ago

A ideia é que em produção a gente use o Jenkins e o Chef. O Vagrant seria só pro ambiente de desenvolvimento. Pelo Vagrant a gente executa numa VM local a mesma receita Chef que o jenkins dispara em produção.

Este vagrantfile deve ser executado por alguem antes de ir para produção, tipo continuous integration manual ou QA ?

Isso mesmo! Na produção, o Vagrant não aparece.

E o objetivo é sim que um commit no master já faça o deploy em produção. Achoq o jenkins já tem um githook, mas pra baixar o código, fazer testes, análise estática etc. Daí se tiver tudo OK ele executa o chef q vai fazer todo o processo de implantação.

gleicon commented 9 years ago

então eu acho que não entendi o problema. Se o vagrantfile está no repo, qualquer um pode dar um vagrant up quando quiser que a maquina sobe e o chef roda né ?

On Thu Dec 18 2014 at 2:04:35 PM Leonardo Leite notifications@github.com wrote:

A ideia é que em produção a gente use o Jenkins e o Chef. O Vagrant seria só pro ambiente de desenvolvimento. Pelo Vagrant a gente executa numa VM local a mesma receita Chef que o jenkins dispara em produção.

Este vagrantfile deve ser executado por alguem antes de ir para produção, tipo continuous integration manual ou QA ?

Isso mesmo! Na produção, o Vagrant não aparece.

E o objetivo é sim que um commit no master já faça o deploy em produção. Achoq o jenkins já tem um githook, mas pra baixar o código, fazer testes, análise estática etc. Daí se tiver tudo OK ele executa o chef q vai fazer todo o processo de implantação.

— Reply to this email directly or view it on GitHub https://github.com/radar-parlamentar/implantacao/issues/5#issuecomment-67507691 .

leonardofl commented 9 years ago

O problema é assim: vc tá desenvolvendo... e vc quer testar o sistema numa VM local antes de mandar pra produção. Pra isso vc usa o Vagrant. E pra por o Radar na VM local o Vagrant vai executar a mesma receita que é executada em produção, o que é bom. Só que a receita implanta o que tá no master. E o que você quer é justamente é testar algo antes de enviar pro master, pois quanto algo chega no master vai pra produção! Deadlock!

gleicon commented 9 years ago

faça a receita implantar o repo corrente, não dá ? ou vc quer gerar o artefato ? se sim, colocar um indicador de versao para passar ao chef vindo do git status...

On Thu Dec 18 2014 at 2:15:04 PM Leonardo Leite notifications@github.com wrote:

O problema é assim: vc tá desenvolvendo... e vc quer testar o sistema numa VM local antes de mandar pra produção. Pra isso vc usa o Vagrant. E pra por o Radar na VM local o Vagrant vai executar a mesma receita que é executada em produção, o que é bom. Só que a receita implanta o que tá no master. E o que você quer é justamente é testar algo antes de enviar pro master, pois quanto algo chega no master vai pra produção! Deadlock!

— Reply to this email directly or view it on GitHub https://github.com/radar-parlamentar/implantacao/issues/5#issuecomment-67509989 .

leonardofl commented 9 years ago

Como assim repo corrente? Humm... a aplicação tá em um repo, e os artefatos de implantação (Vagrant + receita Chef estão em outro). Pelo oq vc falou eu teria q deixar tudo no mesmo repo. Além disso, na hora em q a receita faz o git clone do master, a gente teria q trocar essa operação por uma cópia no filesystem (da pasta compartilhada do vagrant para onde o repositório era clonado). Então na real eu teria q ter uma flag na receita Chef do tipo "isInVagrant". Parece ser esse o caminho?

leonardofl commented 9 years ago

Obs: a aplicação é python, não tem artefato pra ser gerado.

gleicon commented 9 years ago

eu geralmente deixo tudo no mesmo repositorio

On Thu Dec 18 2014 at 2:23:03 PM Leonardo Leite notifications@github.com wrote:

Obs: a aplicação é python, não tem artefato pra ser gerado.

— Reply to this email directly or view it on GitHub https://github.com/radar-parlamentar/implantacao/issues/5#issuecomment-67511588 .

leonardofl commented 9 years ago

humm.... vou colocar aqui a motivação pra ter separado os repositórios. É que a receita Chef faz o git clone do repo da aplicação... mas se a receita estiver no próprio repo isso implica em um primeiro git clone para obter a receita, e depois outro git clone do mesmo repo pela receita para obter a aplicação. Então pra evitar o git clone duas vezes do mesmo repo resolvemos separar os repos pra ficar um pouco mais elegante, embora continue rolando dois git clones.

Mas pela conversa, agora me parece q o mais adequado seria deixar tudo no mesmo repo, e tirar o git clone da receita. Assim, temos:

Em dev: vagrant compartilha com a VM o repositório de trabalho, com mudanças não commitadas; vagrant executa receita chef que instala toda a infra (mas não baixa o repo, ele já tá lá).
Em produção: job do jenkins faz duas cosias: baixa/atualiza o repo da aplicação (que inclui a receita Chef); e executa a receita Chef.

Obs: job do jenkins que eu digo é o que é executado depois que ele já executou os testes da integração contínua.

Assim parece que as coisas se acomodam melhor. Único desporém que no começo eu não via com bons olhos era essa coisa de o job jenkins fazer mais de uma coisa além de executar a receita Chef, que deveria ser a responsável por saber como instalar o Radar. Por outro lado, se o jenkins tem q saber baixar o repo da receita, pq não saber como baixar o repo da app, neh?

Valeu Gleicon!

leonardofl commented 8 years ago

Opa, já que a galera levantou de novo essa bola e de fato resolver isso ajudaria mt na vida de novos membros do projeto, pensei um pouco mais no assunto e tenho a seguinte proposta:

O repositório implantação continua do jeito que tá (exceto por algumas alteração na receita radar:default, que falarei mais a frente).
O repositório radar passa a ter um Vagrantfile e um script de implantação próprio.
Esse script de implantação pode ser um shell script mesmo que faria o seguinte:
Clonar o repositório implantação na VM;
Instala o Chef;
roda "./config vagrant"
roda receita radar:default

A receita radar:default teria as seguintes diferenças:

Clona o repo do radar se usuário != vagrant (é oq já faz hj).
Se usuário == vagrant, então copia o código da pasta na qual os arquivos do desenvolvedor são sincronizados na VM.
Mais pra frente, se usuário != vagrant então usa o settings/production.py (oq já faz hj).
Se usuário == vargant, então usa um settings/vagrant.py q seria basicamente o production.py só que sem cache.

Acho que algo assim deve rolar. O que acham da ideia?

davidCarlos commented 8 years ago

Por mim fica tranquilo Leo, apesar de eu não ter entendido bem o porque de ter um repositório de implantação separado(eu li seu comentário ali em cima).

davidCarlos commented 8 years ago

A gente pode cogitar a ideia de fazer um pacote .deb para o radar, facilitaria muito o deploy em ambientes de produção/homologação.

diraol commented 8 years ago

@hsvab topa empacotar o Radar? rs

davidCarlos commented 8 years ago

Se acharem uma boa empacotar o radar posso ajudar nessa tarefa

leonardofl commented 8 years ago

Hummm... acho q o principal agora é facilitar no ambiente do desenvolvedor. Em produção já roda a receita q baixa do repositório a última versão do código. Não creio que empacotar compensaria muito...

E sim david, outra opção seria juntar tudo em um só repositório. Mas só o código daqui de implantação tem tanta coisa, q eu acho interessante manter a separação... mas é de se pensar unificar os dois repos.

leonardofl commented 8 years ago

Nessa d facilitar pro dev, criar uma box vagrant dp radar (q o Di sugeriu) é uma boa. Mas pro cara desenvolver e ir testando seu código na VM eu faria essa box a partir do esquema d script q eu propus, pq aí o cara cria rápido a vm e atualiza fácil esse ambiente.

Vou pensar mais sobre a unificação dos repos pra ver como isso simplificaria as coisas...

radar-parlamentar / implantacao

Código em desenvolvimento no Vagrant #5