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).
4. I am not teaching you anything. I just help you to explore yourself. If you want to learn to swim jump into the water. On dry land no frame of mind is ever going to help you.
6. Desenvolvimento em Série Quando alguém está a trabalhar num ou mais artefactos tem exclusividade sobre ele e mais ninguém lhe pode mexer
7.
8.
9.
10. TEM DE HAVER UMA MANEIRA MELHOR... UM POUCO MAIS FLEXÍVEL
11. Conway Law “...organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.” http://en.wikipedia.org/wiki/Conway%27s_Law
12. Meu Corolário 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...
13.
14. Isto anda tudo ligado... Padrões Organizacionais Padrões Arquitecturais Padrões Organização de código (dia-a-dia) Padrões “Formação” de código (a genese)
15. Padrões Organizacionais TODO: meter o diagrama do livro Vão ter de imaginar. O meu scanner não funciona no Windows 7 :) Página 100
19. Controlo de Versões Máquina do tempo Permite reconstruir e perceber o passado e a evolução do código fonte...
20. Controlo de Versões Máquina do tempo Permite reconstruir e perceber o passado e a evolução do código fonte...
21. Controlo de Versões Máquina do tempo Permite reconstruir e perceber o passado e a evolução do código fonte...
22. Controlo de Versões Máquina do tempo Permite reconstruir e perceber o passado e a evolução do código fonte...
23. Source Control Moderno Características Expectáveis Operaçõesatómicas Marcação de código (taggingoulabelling) Branching Merging Merge through Rename Navegaçãorepositório Cliente Web
24. Source Control Moderno Características Expectáveis Operaçõesatómicas Marcação de código (taggingoulabelling) Branching Merging Merge through Rename Navegaçãorepositório Cliente Web
25. Source Control Moderno Características Expectáveis Operaçõesatómicas Marcação de código (taggingoulabelling) Branching Merging Merge through Rename Navegaçãorepositório Cliente Web
32. Source Control: Terminologia Mainlineou trunk – Árvore principal de desenvolvimento. Possui os desenvolvimentos mais actuais. Branch– A separação de um item (directoria, ficheiro) para um caminho alternativo. Os caminhos são independentes. Label ou Tag– Define um snapshot de uma árvore de desenvolvimento a um dado momento. Auxílio para definição de uma baseline.
34. Codeline por Versão / Release Existe uma árvore de desenvolvimento distinta para cada versão Que terá que ser mantida Adequada para o desenvolvimento de produtos
35. Codeline por Ambiente Se substituirmos versão por ambiente, temos um padrão mais adequado a empresas que não desenvolvem produtos O código é promovido entre ambientes à medida das necessidades Eg: desenvolvimento, testes, qualidade e produção.
36. Um método possível Uma árvore de desenvolvimento Trunk A raiz deve ser muito pequena Aconselhável criar especificamente um trunk na raiz. Facilita o branching. Ao colocar criar uma versão colocar-lhe uma label Permite reproduzir a qualquer altura uma dada versão 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. Corrigir o bug no branch, e fazer o merge para os ambientes necessários (forward merge)
37. Cuidados a ter no Check-In Os check-insdevem ser atómicos Não devemos misturar diferentes tarefas no mesmo check-in Uma tarefa por check-in apenas Estas práticas facilitam a rastreabilidade Nota: Para sistemas em que existe capacidade de ligação entre código e tarefas
38. All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns Bruce Lee
41. Estruturação Árvore Desenvolvim. Não existe uma maneira pré-definida de estruturação de código... O sistema de controlo de versões não deve qualquer obrigação ou coloca restrição na estruturação da árvore de desenvolvimento Mas existem algumas práticas que facilitam o processo de desenvolvimento
42. Práticas de Estruturação? Escrever um documento com as convenções e práticas a utilizar na estruturação de código 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
44. Estruturação de um Projecto Na raiz criar uma directoria com o nome do projecto (raiz do projecto) Não colocar ficheiros na raiz do projecto A raiz do projecto contém apenas directorias Para cada um dos branches Dar um nome bem definido para a arvore principal (eg trunk, mainline). Este nome será comum a todos os projectos
45. Árvore de Projecto Definir uma convenção para estruturação das directorias do projecto e seguí-las em todos os projectos Previsibilidade e ajudam a comunicação e à adaptação de um projecto Reduz Custo de entrada Aumenta productividade Reduz erros
46. Sugestão para Árvore de Projecto Projecto A Trunk – Directoria principal. Contém o(s) ficheiro(s) da(s) solução(ões) Solution Items Dependencies –Bibliotecas licenciadas , bibliotecas comuns entre projecto Installation – Ficheiros para criar o instalador da aplicação Source – Código fonte da aplicação. Estruturar por módulos ou por tecnologia. Contém os ficheiros de projecto de Visual Studio Módulo 1 Modulo 2 Módulo ... Tests Unit Load Manual Integration ...
47. Agregação de Código Solution – Pode Conter: Um mais projectos Ficheiros (Item) Directorias virtuais (solution folders) Project – Contém Tem um tipo Cada tipo poderá ter caracteristicas distintas Referências para outros projectos (dependencias) da solução Referências a DLLs Código Ficheiros
48. Estruturação da Solução Utilizar Solution Folders Mapeia areas lógicas da solução Facilita a organização e navegação no código Não tem que ser um mapeamento directo para as directorias de projecto
49. Código Comum a vários Projectos Colocado na directoria Dependencies Gerido tal e qual se fosse um componente desenvolvido por uma entidade externa (eg: biblioteca de gráficos) Não ligar directamente ao código-fonte do projecto comum Será feito o upgrade para uma nova versão quando a equipa o entender e não sempre que é feita uma alteração
50. O que ficou de fora? Builds Rastreabilidade Ligação a outros sistemas: Testes Requisitos Bugs
51. Em Suma Repositório centralizado de todos os artefactos Código fonte Scripts Modelo de dados Scripts de instalação Teste do Algodão Instalar uma nova máquina, ligá-la à rede, obter a última versão do repositório É possível compilar o código sem processos manuais?
53. Referências CM Patterns for Agility http://www.scmpatterns.com Microsoft Team Foundation Server Branching Guidance http://www.codeplex.com/BranchingGuidance Visual Studio TFS Branching Guide 2010 http://tfsbranchingguideiii.codeplex.com