Lidando com GIT, dependências e app/bootstrap

[Thiago Rodrigues]

A instalação do Symfony2 e a manutenção das dependências usando composer é fantástica, mas durante a configuração do git deparei com a recomendação de .gitignore do cookbook do Symfony2[1].

Eles sugerem deixar fora do git:

/web/bundles/
/app/bootstrap*
/app/cache/*
/app/logs/*
/vendor/
/app/config/parameters.ini

Os arquivos que casam com a regex /app/bootstrap* e /vendor/ são gerados automáticamente pelo composer (install ou update). Assim, código escrito por terceiros fica fora do git.

Mas a minha dúvida:

Caso os fontes de alguma dependência fique offline, seja por indisponibilidade momentânea (por algum tipo de falha no servidor/rede) ou definitiva (ex: remoção do repositório no github), de que modo posso instalar tal dependência?

Olhando o composer.json vi que ele executa a seguinte ação tanto na instalação quanto no update:

"Sensio\\Bundle\\DistributionBundle\\Composer\\ScriptHandler::buildBootstrap"

Como executá-la manualmente?

E na prática, vocês mantém as dependências controladas pelo git (seja no mesmo repositório ou em outro) ou seguem a recomendação do cookbook?

[1] - http://symfony.com/doc/2.0/cookbook/workflow/new_project_git.html

Atenciosamente,

Thiago Rodrigues
http://xthiago.net/

[Mateus Martins]

Ola Thiago, blz?

Eu tenho usado o Synfony2 há um pouco mais de um ano e tenho deixado fora do .git somente:

/bin/doctrine
/bin/doctrine.php
/web/bundles
/app/cache/dev
/app/cache/prod
/app/logs

O Synfony2 costuma lançar pacotes intermediários com pequenas mudanças então tento deixar o máximo do projeto salvo no repositório.

2013/3/11 Thiago Rodrigues <xth...@gmail.com>

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Symfony Brasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para symfony-pt+...@googlegroups.com.
Para postar neste grupo, envie um e-mail para symfo...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/symfony-pt?hl=pt-BR.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

[Paulo Roberto Ribeiro]

Olá,

eu utilizo a recomendação do artigo. Confesso que também fico pensativo sobre uma eventual indisponibilidade das bibliotecas que utilizo. Hoje conto com a sorte e assumo que estarão sempre disponíveis quando for preciso.

2013/3/11 Thiago Rodrigues <xth...@gmail.com>

--

Você está recebendo esta mensagem porque se inscreveu no grupo "Symfony Brasil" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para symfony-pt+...@googlegroups.com.
Para postar neste grupo, envie um e-mail para symfo...@googlegroups.com.
Visite este grupo em http://groups.google.com/group/symfony-pt?hl=pt-BR.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Cordialmente,


Paulo Roberto Ribeiro

[Rafael Goulart]

Paulo,

Não acho necessário contar com a sorte. 

Já tens as bibliotecas em sua máquina; se quiser uma garantia adicional, sempre pode clonar em outro diretório e apontar para lá a referência do composer.

Podes até fazer um fork no GitHub e apontar para o seu repositório, e não o original, para segurança pessoal.

http://getcomposer.org/doc/05-repositories.md#vcs

[]'s

Rafael Goulart

[Thiago Rodrigues]

Olá pessoal, obrigado pelos esclarecimentos.

Att.

Thiago Rodrigues
http://xthiago.net/

[Paulo Roberto Ribeiro]

Rafael,

valeu pela dica.

Realmente dá para fazer o que disse. No meu caso, temos um servidor GIT próprio e poderíamos mander uma cópia dos projetos que utilizamos lá. Com o GIT é fácil fácil fazer isso. Clonamos o projeto, e adicionamos nosso repo como um 2o remote repo. Aí basta dar pull do origin e push para o nosso e está tudo seguro. ;-)

OBS: Toda vez que sou levado a pensar nas facilidades do GIT, eu penso "como pude usar tanto tempo o SVN?!?!?!"... e depois dá uma vontade de  "hey, SVN, vai a @#$^%$&".... hahahaha... depois que migramos os primeiros projetos para o GIT, nunca mais usei SVN, já faz uns 18-24 meses.

2013/3/11 Rafael Goulart <rafa...@gmail.com>

[Rafael Goulart]

Paulo,

Exatamente isto. E, realmente, o GIT é muito mais tranquilo, leve e versátil que o SVN. Mas eu agradeço ao SVN, pois ele nos deu uma ótima opção ao CVS... 

O importante é termos opções para todos os gostos e necessidades. 

[]'s

Rafael

[Paulo Roberto Ribeiro]

Boa tarde, pessoal,

sobre servidores git. Até uns 2 meses atrás eu estava utilizando o gitolite para administrar o servidor. Funciona bem, mas dava a sensação de ser muito manual e com a administração muito restrita a quem tinha conhecimento em administrar servidor linux.

Aí resolvi testar o Stash ( http://www.atlassian.com/software/stash/overview ). O software é realmente demais. Além disso, para até 10 usuário é US$10,00/ano. Não troco tão cedo.

2013/4/11 Gilmar Pupo <gilma...@gmail.com>

Muito bem senhores!

Ferramentas boas pelo preço de poucas horas de estudo e assim caminhamos na boa índole software that respects users' freedom and community  :D

Meu amigo Rafael,
aproveito o tópico para uma pergunta off-topic que iria lhe fazer em nossas conversas mas quem sabe alguem mais tenha interesse.

No ano passado falamos sobre servidores Git e apps gestores de identidade e permissões de repositório.

Como ficou a receita secreta final para este bolo ?

[]s a todos e aproveito para dizer que estou lendo tudo apesar do pouco tempo de participar da melhor comunidade PHP em PT-BR que conheço.

@gpupo

[Marcelo Rodrigues]

Paulo, 

Aqui também usamos o GITOLITE, ele é chato de instalar no início, mas para gerenciar achei muito tranquilo. Usamos o GitLab, um "Github" genérico, digamos assim, opensource, para projetos internos. Para nós, foi uma mão na roda. 

http://gitlab.org/

Marcelo

[Marcelo Rodrigues]

Em tempo, o GitLab usa o Gitolite para gerenciar usuários, repositórios e permissões nos projetos. 

[Rafael Goulart]

Gilmar,

As opções que temos dependem do tamanho da equipe, quantidade de repositórios, necessidade ou não de interface gráfica, necessidade ou não de recursos além do gerenciamento do repositório em si (gerenciador de projetos).

Opção básica: Gitolite. Basicamente, um script em Python muito consistente que permite administrar chaves públicas de usuário e relacioná-las a repositórios, branchs, entre outros objetos, através da manipulação de um repositório simples um arquivo de configuração. FUNCIONA MUITO BEM, mas a administração é na mão (edita conf, inclui chave, commit, push)

Com Gerenciador de projetos (e/ou interface gráfica), tem-se outras opções:

- GitLab: que está se sedimentado, é um clone do GiHub que trabalha em cima do Gitolite (mas na próxima versão vai utilizar sua própria biblioteca para isto). Em Ruby. Repository centric (um projeto = um repositório)

- Gitorious: na mesma linha GitLab, mas com menos recursos. Em Ruby. Project centric (um projeto = vários repositórios)

- Redmine + Git e/ou Gitolite: existe um plugin para administrar repositórios no Redmine através do Gitolite, não cheguei a testar. Na última versão do Redmine permite criar um PROJETO vincular com vários REPOSITÓRIOS (project centric).

Cheguei a criar um wrapper em PHP para administrar o Gitolite (https://github.com/rafaelgou/gitolite-php), que seria base para criar uma ferramenta administrativa. Mas, olhando a proposta do GitLab de criar uma ferramenta própria (https://github.com/gitlabhq/gitlab-shell), vi que não é tão complexo, basicamente é feito através dos hooks.

Se me perguntarem o que acho do GitLab... sendo em Ruby não fiquei muito confortável com a instalação, que me pareceu onerosa em termos de memória (simplesmente não rodou num servidor meu com 512Mb). Mas não insisti, admito. Para quem gosta do GitHub, é um caminho muito confortável MESMO.

Redmine para mim te induz a um padrão de gerenciamento antigo, não digo que é impossível trabalhar um projeto ágil nele, mas eu me sinto muito desconfortável.

Não conhecia o Stash, Paulo Ribeiro, vou dar uma olhada, mesmo não sendo FOSS.

Tempos atrás criei um simples administrador de repositórios em SF 1.4 para o Gitolite, mas foi para um cliente, não posso publicar como FOSS. Mas tenho muita vontade de fazer uma ferramenta em SF2 + MongoDB.

[]'s

Rafael Goulart

Em 11 de abril de 2013 23:26, Gilmar Pupo <gilma...@gmail.com> escreveu:

Muito bem senhores!

Ferramentas boas pelo preço de poucas horas de estudo e assim caminhamos na boa índole software that respects users' freedom and community  :D

Meu amigo Rafael,
aproveito o tópico para uma pergunta off-topic que iria lhe fazer em nossas conversas mas quem sabe alguem mais tenha interesse.

No ano passado falamos sobre servidores Git e apps gestores de identidade e permissões de repositório.

Como ficou a receita secreta final para este bolo ?

[]s a todos e aproveito para dizer que estou lendo tudo apesar do pouco tempo de participar da melhor comunidade PHP em PT-BR que conheço.

@gpupo

Em quinta-feira, 11 de abril de 2013 08h05min15s UTC-3, Rafael Goulart  escreveu:

[Gilmar Pupo]

A dois anos troquei o Gitosis  pelo Github.

Infelizmente neste ano durante muitos momentos enfrentamos indisponibilidade dos servidores Github em função dos ataques que receberam.

No ano passado eu havia gostado da idéia do Gitlab e acredito que vou testar esta solução.

Obrigado pelas sugestões e obrigado pelos peixes.

[]s

@gpupo

[Pedro Casado]

Ha 6 meses nos tb trocamos o gitosis pelo Github. Ate entao ainda nao tivemos nenhum problema com Github.

[Romeu Godoi]

Aqui usávamos o gitosis e mudamos para o gitolite + redmine, pois precisávamos de um controle de permissão mais robusto para implementar um processo de deploy através do Git. 

O gitolite resolveu o problema para o deploy+notificação+rsync, mas fiquei curioso pra conhecer o GitLab, pra ficar legal, precisava integrá-lo com o redmine para as referências entre as issues e os commits, etc.

Devo testá-lo logo. Valeu galera!

Att, 

Romeu Godoi

Desenvolvedor Web
Blog: romeugodoi.wordpress.com
Twitter: @romeugodoi

Skype: romeu.godoi

 

Os obstáculos são essas coisas aterradoras que um vê quando aparta os olhos da sua meta.  

Henry Ford

Proteja o endereço de seus amigos como estou protegendo o seu. Ao enviar
mensagens para mais de um endereço use SEMPRE o "Cco" (cópia oculta ou "Bcc" (Blind carbon copy)).

[Marcelo Rodrigues]

O Gitlab tem seu próprio sistema de ISSUES. Mas acredito que não seja muito complicado integrar com outras ferramentas usando os hooks. Com o Redmine isso deve mais tranquilo ainda, uma vez que ambos são escritos em Ruby :)

Marcelo

2013/5/17 Romeu Godoi <romeu...@gmail.com>

O gitolite resolveu o problema para o deploy+notificação+rsync, mas fiquei curioso pra conhecer o GitLab, pra ficar legal, precisava integrá-lo com o redmine para as referências entre as issues e os commits, etc.

--
Marcelo Rodrigues

Analista Desenvolvedor

Zend Certified Engineer ZEND018059

+55 (61) 9273 2058

http://www.marcelomx.com