http://netponto.org<br />12ª Reunião Presencial - 10/07/2010<br />Estratégias de Estruturação de Código-fonte e Controlo d...
Tiago Pascoal<br />tiago.pascoal@agilior.pt<br />http://agilior.pt/blogs/tiago.pascoal<br />
Agenda<br />Arquitectura?<br />Padrões?<br />Código?<br />Estruturas?<br />Veremos….<br />
I am not teaching you anything. <br />I just help you to explore yourself.<br />If you want to learn to swim jump into the...
Aviso...<br />
Desenvolvimento em Série<br />Quando alguém está a trabalhar num ou mais artefactos tem exclusividade sobre ele e mais nin...
TEM DE HAVER UMA MANEIRA MELHOR... UM POUCO MAIS FLEXÍVEL<br />
Conway Law<br />“...organizations which design systems ... are constrained to produce designs which are copies of the comm...
Meu Corolário<br />A qualidade e a fluidez do desenvolvimento está dependente da estrutura e organização do código, mas ac...
Desenvolvimento Concorrente<br /><ul><li>Modelo de concorrência optimista. Várias pessoas podem mexer no mesmo artefacto e...
Isto anda tudo ligado...<br />Padrões Organizacionais<br />Padrões Arquitecturais<br />Padrões Organização de código (dia-...
Padrões Organizacionais<br />TODO: meter o diagrama do livro<br />Vão ter de imaginar. O meu scanner não funciona no Windo...
Padrões de Organização de Código<br />
Ou estas...<br />
Padrões<br />
Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
Source Control Moderno<br />Características Expectáveis<br />Operaçõesatómicas<br />Marcação de código  (taggingoulabellin...
Source Control Moderno<br />Características Expectáveis<br />Operaçõesatómicas<br />Marcação de código  (taggingoulabellin...
Source Control Moderno<br />Características Expectáveis<br />Operaçõesatómicas<br />Marcação de código  (taggingoulabellin...
Dinossauro<br />
Dinossauro<br />
Dinossauro<br />
E os Sistemas Distribuídos? (DVCS)<br />TeamWare   (90s)<br />Code Co-op (97)<br />GNU Arch<br />Darcs<br />SVK<br />Mercu...
Cool Kids<br />
Cool Kids<br />
Source Control: Terminologia<br />Mainlineou trunk – Árvore principal de desenvolvimento.  Possui os desenvolvimentos mais...
Padrões de OrganizaçãoControlo de Versões<br />
Codeline por Versão / Release<br />Existe uma árvore de desenvolvimento distinta para cada versão<br />Que terá que ser ma...
Codeline por Ambiente<br />Se substituirmos versão por ambiente, temos um padrão mais adequado a empresas que não desenvol...
Um método possível<br />Uma árvore de desenvolvimento Trunk<br />A raiz deve ser muito pequena<br />Aconselhável criar esp...
Cuidados a ter no Check-In<br />Os check-insdevem ser atómicos<br />Não devemos misturar diferentes tarefas no mesmo check...
All fixed set patterns are incapable of adaptability or pliability. <br />The truth is outside of all fixed patterns<br />...
Estruturação de um Projecto<br />
Obey the principles without being bound by them<br />Bruce Lee<br />
Estruturação Árvore Desenvolvim.<br />Não existe uma maneira pré-definida de estruturação de código...<br />O sistema de c...
Práticas de Estruturação?<br />Escrever um documento com as convenções e práticas a utilizar na estruturação de código<br ...
Estruturação de um Projecto<br />Uma prática possível...<br />
Estruturação de um Projecto<br />Na raiz criar uma directoria com o nome do projecto (raiz do projecto)<br />Não colocar f...
Árvore de Projecto<br />Definir uma convenção para estruturação das directorias do projecto e seguí-las em todos os projec...
Sugestão para Árvore de Projecto<br />Projecto A<br />Trunk – Directoria principal. Contém o(s) ficheiro(s) da(s) solução(...
Agregação de Código<br />Solution – Pode Conter:<br />Um mais projectos<br />Ficheiros (Item)<br />Directorias virtuais (s...
Estruturação da Solução<br />Utilizar Solution Folders <br />Mapeia areas lógicas da solução<br />Facilita a organização e...
Código Comum a vários Projectos<br />Colocado na directoria Dependencies<br />Gerido tal e qual se fosse um componente des...
O que ficou de fora?<br />Builds<br />Rastreabilidade<br />Ligação a outros sistemas:<br />Testes<br />Requisitos<br />Bug...
Em Suma<br />Repositório centralizado de todos os artefactos<br />Código fonte<br />Scripts<br />Modelo de dados<br />Scri...
Questões?<br />
Referências<br />CM Patterns for Agility<br />http://www.scmpatterns.com<br />Microsoft Team Foundation Server Branching G...
Patrocinadores desta reunião<br />
Próximas reuniões presenciais<br />10/07/2010 - Julho<br />14/08/2010 - Agosto<br />18/09/2010 - Setembro<br />23/10/2010 ...
Obrigado!<br />Tiago Pascoal<br />tiago.pascoal@agilior.pt<br />http://agilior.pt/blogs/tiago.pascoal<br />
Estratégias de Estruturação de Código-fonte e Controlo de Versão
Próximos SlideShares
Carregando em…5
×

Estratégias de Estruturação de Código-fonte e Controlo de Versão

1.822 visualizações

Publicada em

Muitas das dificuldades no desenvolvimento profissional de software são causadas por problemas (ou a falta de) um correcto sistema e uso de controlo de versões. Nesta apresentação o Tiago Pascoal, MVP em Visual Studio Team System, irá mostrar estratégias sobre como melhor estruturar todos os artefactos de um projecto, incluindo melhores práticas para uso de controlo de versões, tendo por base a plataforma de Application Lifecycle Management da Microsoft (Team Foundation Server / TFS).

Publicada em: Tecnologia
  • Seja o primeiro a comentar

Estratégias de Estruturação de Código-fonte e Controlo de Versão

  1. 1. http://netponto.org<br />12ª Reunião Presencial - 10/07/2010<br />Estratégias de Estruturação de Código-fonte e Controlo de VersãoTiago Pascoal<br />
  2. 2. Tiago Pascoal<br />tiago.pascoal@agilior.pt<br />http://agilior.pt/blogs/tiago.pascoal<br />
  3. 3. Agenda<br />Arquitectura?<br />Padrões?<br />Código?<br />Estruturas?<br />Veremos….<br />
  4. 4. I am not teaching you anything. <br />I just help you to explore yourself.<br />If you want to learn to swim jump into the water. On dry land no frame of mind is ever going to help you.<br />
  5. 5. Aviso...<br />
  6. 6. Desenvolvimento em Série<br />Quando alguém está a trabalhar num ou mais artefactos tem exclusividade sobre ele e mais ninguém lhe pode mexer<br />
  7. 7.
  8. 8.
  9. 9.
  10. 10. TEM DE HAVER UMA MANEIRA MELHOR... UM POUCO MAIS FLEXÍVEL<br />
  11. 11. Conway Law<br />“...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.”<br />http://en.wikipedia.org/wiki/Conway%27s_Law<br />
  12. 12. Meu Corolário<br />A qualidade e a fluidez do desenvolvimento está dependente da estrutura e organização do código, mas acima de tudo pela flexibilidade e dos padrões oferecidos pelo sistema de controlo de versões...<br />
  13. 13. Desenvolvimento Concorrente<br /><ul><li>Modelo de concorrência optimista. Várias pessoas podem mexer no mesmo artefacto e só em caso de conflito será necessário intervenção humana</li></li></ul><li>Mas e a arquitectura senhor?<br />O que é que isto tem a ver com arquitectura?<br />hei-de ouvir o teu parecerhás-de me dizerhás-de me dizerhás-de me dizerse é cada coisa para seu ladoou se isto anda tudo ligado<br /> Sérgio Godinho<br />
  14. 14. Isto anda tudo ligado...<br />Padrões Organizacionais<br />Padrões Arquitecturais<br />Padrões Organização de código (dia-a-dia)<br />Padrões “Formação” de código (a genese)<br />
  15. 15. Padrões Organizacionais<br />TODO: meter o diagrama do livro<br />Vão ter de imaginar. O meu scanner não funciona no Windows 7 :)<br />Página 100<br />
  16. 16. Padrões de Organização de Código<br />
  17. 17. Ou estas...<br />
  18. 18. Padrões<br />
  19. 19. Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
  20. 20. Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
  21. 21. Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
  22. 22. Controlo de Versões<br />Máquina do tempo<br />Permite reconstruir e perceber o passado e a evolução do código fonte...<br />
  23. 23. Source Control Moderno<br />Características Expectáveis<br />Operaçõesatómicas<br />Marcação de código (taggingoulabelling)<br />Branching<br />Merging<br />Merge through Rename<br />Navegaçãorepositório<br />Cliente<br />Web<br />
  24. 24. Source Control Moderno<br />Características Expectáveis<br />Operaçõesatómicas<br />Marcação de código (taggingoulabelling)<br />Branching<br />Merging<br />Merge through Rename<br />Navegaçãorepositório<br />Cliente<br />Web<br />
  25. 25. Source Control Moderno<br />Características Expectáveis<br />Operaçõesatómicas<br />Marcação de código (taggingoulabelling)<br />Branching<br />Merging<br />Merge through Rename<br />Navegaçãorepositório<br />Cliente<br />Web<br />
  26. 26. Dinossauro<br />
  27. 27. Dinossauro<br />
  28. 28. Dinossauro<br />
  29. 29. E os Sistemas Distribuídos? (DVCS)<br />TeamWare (90s)<br />Code Co-op (97)<br />GNU Arch<br />Darcs<br />SVK<br />Mercurial<br />Bazaar<br />Git<br />
  30. 30. Cool Kids<br />
  31. 31. Cool Kids<br />
  32. 32. Source Control: Terminologia<br />Mainlineou trunk – Árvore principal de desenvolvimento. Possui os desenvolvimentos mais actuais.<br />Branch– A separação de um item (directoria, ficheiro) para um caminho alternativo. Os caminhos são independentes.<br />Label ou Tag– Define um snapshot de uma árvore de desenvolvimento a um dado momento. Auxílio para definição de uma baseline.<br />
  33. 33. Padrões de OrganizaçãoControlo de Versões<br />
  34. 34. Codeline por Versão / Release<br />Existe uma árvore de desenvolvimento distinta para cada versão<br />Que terá que ser mantida<br />Adequada para o desenvolvimento de produtos<br />
  35. 35. Codeline por Ambiente<br />Se substituirmos versão por ambiente, temos um padrão mais adequado a empresas que não desenvolvem produtos<br />O código é promovido entre ambientes à medida das necessidades<br />Eg: desenvolvimento, testes, qualidade e produção.<br />
  36. 36. Um método possível<br />Uma árvore de desenvolvimento Trunk<br />A raiz deve ser muito pequena<br />Aconselhável criar especificamente um trunk na raiz. Facilita o branching.<br />Ao colocar criar uma versão colocar-lhe uma label<br />Permite reproduzir a qualquer altura uma dada versão<br />Se necessário corrigir um bug numa dada versão e não for possível colocar a versão em produção, criar um branch a partir da label.<br />Corrigir o bug no branch, e fazer o merge para os ambientes necessários (forward merge)<br />
  37. 37. Cuidados a ter no Check-In<br />Os check-insdevem ser atómicos<br />Não devemos misturar diferentes tarefas no mesmo check-in<br />Uma tarefa por check-in apenas<br />Estas práticas facilitam a rastreabilidade<br />Nota: Para sistemas em que existe capacidade de ligação entre código e tarefas<br />
  38. 38. All fixed set patterns are incapable of adaptability or pliability. <br />The truth is outside of all fixed patterns<br />Bruce Lee<br />
  39. 39. Estruturação de um Projecto<br />
  40. 40. Obey the principles without being bound by them<br />Bruce Lee<br />
  41. 41. Estruturação Árvore Desenvolvim.<br />Não existe uma maneira pré-definida de estruturação de código...<br />O sistema de controlo de versões não deve qualquer obrigação ou coloca restrição na estruturação da árvore de desenvolvimento<br />Mas existem algumas práticas que facilitam o processo de desenvolvimento<br />
  42. 42. Práticas de Estruturação?<br />Escrever um documento com as convenções e práticas a utilizar na estruturação de código<br />A estruturação pode não ser perfeita, mas a consistência facilita a comunicação, a migração entre equipas e o processo de desenvolvimento<br />
  43. 43. Estruturação de um Projecto<br />Uma prática possível...<br />
  44. 44. Estruturação de um Projecto<br />Na raiz criar uma directoria com o nome do projecto (raiz do projecto)<br />Não colocar ficheiros na raiz do projecto<br />A raiz do projecto contém apenas directorias<br />Para cada um dos branches<br />Dar um nome bem definido para a arvore principal (eg trunk, mainline). Este nome será comum a todos os projectos<br />
  45. 45. Árvore de Projecto<br />Definir uma convenção para estruturação das directorias do projecto e seguí-las em todos os projectos<br />Previsibilidade e ajudam a comunicação e à adaptação de um projecto<br />Reduz Custo de entrada<br />Aumenta productividade<br />Reduz erros<br />
  46. 46. Sugestão para Árvore de Projecto<br />Projecto A<br />Trunk – Directoria principal. Contém o(s) ficheiro(s) da(s) solução(ões)<br />Solution Items<br />Dependencies –Bibliotecas licenciadas , bibliotecas comuns entre projecto<br />Installation – Ficheiros para criar o instalador da aplicação<br />Source – Código fonte da aplicação. Estruturar por módulos ou por tecnologia. Contém os ficheiros de projecto de Visual Studio<br />Módulo 1<br />Modulo 2<br />Módulo ...<br />Tests<br />Unit<br />Load<br />Manual<br />Integration<br />...<br />
  47. 47. Agregação de Código<br />Solution – Pode Conter:<br />Um mais projectos<br />Ficheiros (Item)<br />Directorias virtuais (solution folders)<br />Project – Contém<br />Tem um tipo<br />Cada tipo poderá ter caracteristicas distintas<br />Referências para outros projectos (dependencias) da solução<br />Referências a DLLs<br />Código<br />Ficheiros<br />
  48. 48. Estruturação da Solução<br />Utilizar Solution Folders <br />Mapeia areas lógicas da solução<br />Facilita a organização e navegação no código<br />Não tem que ser um mapeamento directo para as directorias de projecto<br />
  49. 49. Código Comum a vários Projectos<br />Colocado na directoria Dependencies<br />Gerido tal e qual se fosse um componente desenvolvido por uma entidade externa (eg: biblioteca de gráficos)<br />Não ligar directamente ao código-fonte do projecto comum<br />Será feito o upgrade para uma nova versão quando a equipa o entender e não sempre que é feita uma alteração<br />
  50. 50. O que ficou de fora?<br />Builds<br />Rastreabilidade<br />Ligação a outros sistemas:<br />Testes<br />Requisitos<br />Bugs<br />
  51. 51. Em Suma<br />Repositório centralizado de todos os artefactos<br />Código fonte<br />Scripts<br />Modelo de dados<br />Scripts de instalação<br />Teste do Algodão<br />Instalar uma nova máquina, ligá-la à rede, obter a última versão do repositório<br />É possível compilar o código sem processos manuais?<br />
  52. 52. Questões?<br />
  53. 53. Referências<br />CM Patterns for Agility<br />http://www.scmpatterns.com<br />Microsoft Team Foundation Server Branching Guidance<br />http://www.codeplex.com/BranchingGuidance<br />Visual Studio TFS Branching Guide 2010<br />http://tfsbranchingguideiii.codeplex.com<br />
  54. 54. Patrocinadores desta reunião<br />
  55. 55. Próximas reuniões presenciais<br />10/07/2010 - Julho<br />14/08/2010 - Agosto<br />18/09/2010 - Setembro<br />23/10/2010 - OutubroReserva estes dias na agenda! :)<br />
  56. 56. Obrigado!<br />Tiago Pascoal<br />tiago.pascoal@agilior.pt<br />http://agilior.pt/blogs/tiago.pascoal<br />

×