Versionamento de Código, Artefatos e Dependências

[Marcelo Rodrigues]

Caros, 

Existe  uma questão que, embora trivial, sempre nos desafia em cada novo projeto, principalmente quando estamos na fase de definição da arquitetura inicial, que é: o que versionar e como versionar todos artefatos de uma aplicação/projeto. 

Estou lendo o livro "Continuous Delivery", e nele é indicado versionar tudo: documentação, diagramas, scripts de banco, build, dependências (bibliotecas, framework, etc), além é claro, do próprio código da aplicação. 

Enfim. A pergunta que fica é: 

- De que forma vocês costumam estruturar o repositório de controle de versão para comportar todos esses elementos?

- Para as dependências, o que é mais interessante: configurar apenas um script de instalação (como um Composer da vida) referenciando o repositório e o diretório local na aplicação, respectivamente, ou versionar juntamente com o código fonte da aplicação e atualizar sob demanda?

- Com o GIT, estruturar e gerenciar essas dependências, ficou muito mais fácil. E no SVN, como vocês costumam fazer?  Só por curiosidade, não usarei SVN, apenas gostaria de referências a respeito. 

--
Marcelo Rodrigues

Analista Desenvolvedor

Zend Certified Engineer ZEND018059

+55 (61) 9273 2058

http://www.marcelomx.com

[Diego Henrique Oliveira]

2012/7/15 Marcelo Rodrigues <marce...@gmail.com>

Caros, 

Existe  uma questão que, embora trivial, sempre nos desafia em cada novo projeto, principalmente quando estamos na fase de definição da arquitetura inicial, que é: o que versionar e como versionar todos artefatos de uma aplicação/projeto. 

Estou lendo o livro "Continuous Delivery", e nele é indicado versionar tudo: documentação, diagramas, scripts de banco, build, dependências (bibliotecas, framework, etc), além é claro, do próprio código da aplicação. 

Enfim. A pergunta que fica é: 

- De que forma vocês costumam estruturar o repositório de controle de versão para comportar todos esses elementos?

Eu geralmente tenho uma pasta chamada docs na raiz do projeto aonde coloco diagramas de banco de dados, documentação sobre workflow e algumas coisas tecnicas (nunca coloquei nada relativo ao négocio aqui, isso geralmente vai em outro lugar.)

Quando aos scripts de banco de dados, eu atualmente uso o Doctrine Migrations (que apesar de ser ligado ao doctrine, pode ser usado sem a sua aplicação usar efetivamente o doctrine, vc só vai ter que fazer na mão os migrations ao invês de obte-los automatico).

Para deploy e building atualmente eu uso o Fabric (http://fabfile.org), mas existem outras excelentes opções, como Capistrano, Make, Phing e shellscript. E os arquivos do fabric vão na pasta raiz do projeto e são versionados ;)

 

- Para as dependências, o que é mais interessante: configurar apenas um script de instalação (como um Composer da vida) referenciando o repositório e o diretório local na aplicação, respectivamente, ou versionar juntamente com o código fonte da aplicação e atualizar sob demanda?

Eu prefiro evitar ao máximo versionar código de outras pessoas, acredito que isso só sirva pra deixar o repositorio inflado e dificultar a manutenção de versões e ate de bugfix (se um bug é corrigido no repositório do projeto vc pode ficar sem esta correção por um bom tempo). Então, neste caso eu prefiro usar o composer (já usei muito o svn externals também, ligado diretamente no branch da versão que eu usava).

- Com o GIT, estruturar e gerenciar essas dependências, ficou muito mais fácil. E no SVN, como vocês costumam fazer?  Só por curiosidade, não usarei SVN, apenas gostaria de referências a respeito. 

Então, na verdade eu prefiro não deixar o git (com o gitmodules) gerenciar isso. Acho que alternativas como Composer (php), PIP (python) e rubygems são muito mais eficiêntes.

Eu escolheria uma delas.

[Bruno Soares]

Em geral utilizo SVN para tudo(código, documentação técnica, negócio, arquitetura, framework, etc...), praticamente todo mundo já entende o conceito e utilização da ferramenta. A integração com o Windows Explorer(via Tortoise) facilita ainda mais. Com isso, fica só o trabalho de administração, pra não virar zona... 

Quanto a convivência disso tudo, basta criar uma pastinha no SVN(<<Nome Sisteam/Projeto>>) com as devidas pastas dentro(Código, Negócio, Projeto, Arquitetura, etc...)

Ah, e o mais importante a meu ver, sempre coloco um Analista ou GP quando tem, dono/responsável pelo repositório. Alguém que se sinta responsável pela organização e sanitização deste repositório. Antes disso sempre acontecia de faltar algo a ser versionado, ou alguém que simplesmente preferia não versionar e só subir a versão final do doc ou código... arrrgggghhhh... vontade de matar? Sim. rs.

Agradeço pela indicação das ferramentas e do livro, parecem bem interessantes. 

Abraços,

Bruno Soares.

--
Atenciosamente,

Bruno Soares.

(21)8838-2127

[Marcelo Rodrigues]

2012/7/15 Diego Henrique Oliveira <con...@diegoholiveira.com>

Caros, 

Existe  uma questão que, embora trivial, sempre nos desafia em cada novo projeto, principalmente quando estamos na fase de definição da arquitetura inicial, que é: o que versionar e como versionar todos artefatos de uma aplicação/projeto. 

Estou lendo o livro "Continuous Delivery", e nele é indicado versionar tudo: documentação, diagramas, scripts de banco, build, dependências (bibliotecas, framework, etc), além é claro, do próprio código da aplicação. 

Enfim. A pergunta que fica é: 

- De que forma vocês costumam estruturar o repositório de controle de versão para comportar todos esses elementos?

Eu geralmente tenho uma pasta chamada docs na raiz do projeto aonde coloco diagramas de banco de dados, documentação sobre workflow e algumas coisas tecnicas (nunca coloquei nada relativo ao négocio aqui, isso geralmente vai em outro lugar.)

Quando aos scripts de banco de dados, eu atualmente uso o Doctrine Migrations (que apesar de ser ligado ao doctrine, pode ser usado sem a sua aplicação usar efetivamente o doctrine, vc só vai ter que fazer na mão os migrations ao invês de obte-los automatico).

Para deploy e building atualmente eu uso o Fabric (http://fabfile.org), mas existem outras excelentes opções, como Capistrano, Make, Phing e shellscript. E os arquivos do fabric vão na pasta raiz do projeto e são versionados ;)

Esse é o meu pensamento também Diego, tanto aos docs quanto aos scripts de migrations, building, deployment etc. Para o processo de build eu costumo usar o Phing ou Ant. Para o deployment, Capistrano ou shellscript mesmo. Agora um ponto em relação ao deployment, no livro que eu mencionei, é indicado que os dados relacionados a senhas (bancos de dados, configuração de ambientes, etc) estejam fora do controle de versão ou se forem versionados, que sejam em um repositório a parte, de forma que apenas pessoas responsáveis pela estrutura de produção tenham acesso a esses dados. 

Como você costuma trabalhar nesse processo? 

Só por curiosidade, para os documentos relacionados ao "negócio" em si, você costuma versioná-los também mas, num repositório a parte?

 

- Para as dependências, o que é mais interessante: configurar apenas um script de instalação (como um Composer da vida) referenciando o repositório e o diretório local na aplicação, respectivamente, ou versionar juntamente com o código fonte da aplicação e atualizar sob demanda?

Eu prefiro evitar ao máximo versionar código de outras pessoas, acredito que isso só sirva pra deixar o repositorio inflado e dificultar a manutenção de versões e ate de bugfix (se um bug é corrigido no repositório do projeto vc pode ficar sem esta correção por um bom tempo). Então, neste caso eu prefiro usar o composer (já usei muito o svn externals também, ligado diretamente no branch da versão que eu usava).

Bingo. Penso e costumo fazer da mesma forma. 

 

- Com o GIT, estruturar e gerenciar essas dependências, ficou muito mais fácil. E no SVN, como vocês costumam fazer?  Só por curiosidade, não usarei SVN, apenas gostaria de referências a respeito. 

Então, na verdade eu prefiro não deixar o git (com o gitmodules) gerenciar isso. Acho que alternativas como Composer (php), PIP (python) e rubygems são muito mais eficiêntes.

Eu escolheria uma delas.

Eu também prefiro não delegar isso ao controle de versão. Apenas questionei por curiosidade mesmo. No SVN eu também usava o externals, mas nunca achei nada inteligente esse tipo de dependência. O Composer, na minha opinião, é a melhor opção para esses casos, atualmente, para o PHP.

[Diego Henrique Oliveira]

2012/7/16 Marcelo Rodrigues <marce...@gmail.com>

2012/7/15 Diego Henrique Oliveira <con...@diegoholiveira.com>

Caros, 

Existe  uma questão que, embora trivial, sempre nos desafia em cada novo projeto, principalmente quando estamos na fase de definição da arquitetura inicial, que é: o que versionar e como versionar todos artefatos de uma aplicação/projeto. 

Estou lendo o livro "Continuous Delivery", e nele é indicado versionar tudo: documentação, diagramas, scripts de banco, build, dependências (bibliotecas, framework, etc), além é claro, do próprio código da aplicação. 

Enfim. A pergunta que fica é: 

- De que forma vocês costumam estruturar o repositório de controle de versão para comportar todos esses elementos?

Eu geralmente tenho uma pasta chamada docs na raiz do projeto aonde coloco diagramas de banco de dados, documentação sobre workflow e algumas coisas tecnicas (nunca coloquei nada relativo ao négocio aqui, isso geralmente vai em outro lugar.)

Quando aos scripts de banco de dados, eu atualmente uso o Doctrine Migrations (que apesar de ser ligado ao doctrine, pode ser usado sem a sua aplicação usar efetivamente o doctrine, vc só vai ter que fazer na mão os migrations ao invês de obte-los automatico).

Para deploy e building atualmente eu uso o Fabric (http://fabfile.org), mas existem outras excelentes opções, como Capistrano, Make, Phing e shellscript. E os arquivos do fabric vão na pasta raiz do projeto e são versionados ;)

Esse é o meu pensamento também Diego, tanto aos docs quanto aos scripts de migrations, building, deployment etc. Para o processo de build eu costumo usar o Phing ou Ant. Para o deployment, Capistrano ou shellscript mesmo. Agora um ponto em relação ao deployment, no livro que eu mencionei, é indicado que os dados relacionados a senhas (bancos de dados, configuração de ambientes, etc) estejam fora do controle de versão ou se forem versionados, que sejam em um repositório a parte, de forma que apenas pessoas responsáveis pela estrutura de produção tenham acesso a esses dados. 

Como você costuma trabalhar nesse processo? 

Então, o que eu faço é o seguinte: para o fabric conectar-se aos servidores de produção, eu uso uma chave ssh (que ai só os usuários que possuem podem fazer deploy).

Quanto as senhas dos servidores de produção e staging, eu faço assim, armazeno um arquivo lá com as configurações, tipo:

/opt/projectName/configurations.ini

E no projeto eu faço um alias para este arquivo. A ideia final é, o arquivo de configuração do projeto já existe no servidor, o deploy só faz um link simbolico pra ele.

 

Só por curiosidade, para os documentos relacionados ao "negócio" em si, você costuma versioná-los também mas, num repositório a parte?

Não, usamos o google sites (ainda ta meio amador esta parte, mas como eu me envolvo pouco nela, nem sei o que sugerir pra melhorar).