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

http://netponto.org12ª Reunião Presencial - 10/07/2010Estratégias de Estruturação de Código-fonte e Controlo de VersãoTiago Pascoal

Tiago Pascoaltiago.pascoal@agilior.pthttp://agilior.pt/blogs/tiago.pascoal

AgendaArquitectura?Padrões?Código?Estruturas?Veremos….

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.

Desenvolvimento em SérieQuando alguém está a trabalhar num ou mais artefactos tem exclusividade sobre ele e mais ninguém lhe pode mexer

TEM DE HAVER UMA MANEIRA MELHOR... UM POUCO MAIS FLEXÍVEL

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

Meu CorolárioA 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...

Desenvolvimento ConcorrenteModelo de concorrência optimista. Várias pessoas podem mexer no mesmo artefacto e só em caso de conflito será necessário intervenção humanaMas e a arquitectura senhor?O que é que isto tem a ver com arquitectura?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 Sérgio Godinho

Isto anda tudo ligado...Padrões OrganizacionaisPadrões ArquitecturaisPadrões Organização de código (dia-a-dia)Padrões “Formação” de código (a genese)

Padrões OrganizacionaisTODO: meter o diagrama do livroVão ter de imaginar. O meu scanner não funciona no Windows 7 :)Página 100

Padrões de Organização de Código

Controlo de VersõesMáquina do tempoPermite reconstruir e perceber o passado e a evolução do código fonte...

Source Control ModernoCaracterísticas ExpectáveisOperaçõesatómicasMarcação de código (taggingoulabelling)BranchingMergingMerge through RenameNavegaçãorepositórioClienteWeb

E os Sistemas Distribuídos? (DVCS)TeamWare (90s)Code Co-op (97)GNU ArchDarcsSVKMercurialBazaarGit

Source Control: TerminologiaMainlineou 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.

Padrões de OrganizaçãoControlo de Versões

Codeline por Versão / ReleaseExiste uma árvore de desenvolvimento distinta para cada versãoQue terá que ser mantidaAdequada para o desenvolvimento de produtos

Codeline por AmbienteSe substituirmos versão por ambiente, temos um padrão mais adequado a empresas que não desenvolvem produtosO código é promovido entre ambientes à medida das necessidadesEg: desenvolvimento, testes, qualidade e produção.

Um método possívelUma árvore de desenvolvimento TrunkA raiz deve ser muito pequenaAconselhável criar especificamente um trunk na raiz. Facilita o branching.Ao colocar criar uma versão colocar-lhe uma labelPermite reproduzir a qualquer altura uma dada versãoSe 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)

Cuidados a ter no Check-InOs check-insdevem ser atómicosNão devemos misturar diferentes tarefas no mesmo check-inUma tarefa por check-in apenasEstas práticas facilitam a rastreabilidadeNota: Para sistemas em que existe capacidade de ligação entre código e tarefas

All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patternsBruce Lee

Obey the principles without being bound by themBruce Lee

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 desenvolvimentoMas existem algumas práticas que facilitam o processo de desenvolvimento

Práticas de Estruturação?Escrever um documento com as convenções e práticas a utilizar na estruturação de códigoA 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

Estruturação de um ProjectoUma prática possível...

Estruturação de um ProjectoNa raiz criar uma directoria com o nome do projecto (raiz do projecto)Não colocar ficheiros na raiz do projectoA raiz do projecto contém apenas directoriasPara cada um dos branchesDar um nome bem definido para a arvore principal (eg trunk, mainline). Este nome será comum a todos os projectos

Árvore de ProjectoDefinir uma convenção para estruturação das directorias do projecto e seguí-las em todos os projectosPrevisibilidade e ajudam a comunicação e à adaptação de um projectoReduz Custo de entradaAumenta productividadeReduz erros

Sugestão para Árvore de ProjectoProjecto ATrunk – Directoria principal. Contém o(s) ficheiro(s) da(s) solução(ões)Solution ItemsDependencies –Bibliotecas licenciadas , bibliotecas comuns entre projectoInstallation – Ficheiros para criar o instalador da aplicaçãoSource – Código fonte da aplicação. Estruturar por módulos ou por tecnologia. Contém os ficheiros de projecto de Visual StudioMódulo 1Modulo 2Módulo ...TestsUnitLoadManualIntegration...

Agregação de CódigoSolution – Pode Conter:Um mais projectosFicheiros (Item)Directorias virtuais (solution folders)Project – ContémTem um tipoCada tipo poderá ter caracteristicas distintasReferências para outros projectos (dependencias) da soluçãoReferências a DLLsCódigoFicheiros

Estruturação da SoluçãoUtilizar Solution Folders Mapeia areas lógicas da soluçãoFacilita a organização e navegação no códigoNão tem que ser um mapeamento directo para as directorias de projecto

Código Comum a vários ProjectosColocado na directoria DependenciesGerido 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 comumSerá feito o upgrade para uma nova versão quando a equipa o entender e não sempre que é feita uma alteração

O que ficou de fora?BuildsRastreabilidadeLigação a outros sistemas:TestesRequisitosBugs

Em SumaRepositório centralizado de todos os artefactosCódigo fonteScriptsModelo de dadosScripts de instalaçãoTeste do AlgodãoInstalar uma nova máquina, ligá-la à rede, obter a última versão do repositórioÉ possível compilar o código sem processos manuais?

ReferênciasCM Patterns for Agilityhttp://www.scmpatterns.comMicrosoft Team Foundation Server Branching Guidancehttp://www.codeplex.com/BranchingGuidanceVisual Studio TFS Branching Guide 2010http://tfsbranchingguideiii.codeplex.com

Próximas reuniões presenciais10/07/2010 - Julho14/08/2010 - Agosto18/09/2010 - Setembro23/10/2010 - OutubroReserva estes dias na agenda! :)

Obrigado!Tiago Pascoaltiago.pascoal@agilior.pthttp://agilior.pt/blogs/tiago.pascoal

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

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

Mais conteúdo relacionado

Mais procurados

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

Mais de Comunidade NetPonto

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