Release Management

1,555 views

Published on

This presentation describes some common release management\'s mistakes and explains some workarounds and Release Management\'s best practices.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,555
On SlideShare
0
From Embeds
0
Number of Embeds
21
Actions
Shares
0
Downloads
42
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • ESTA APRESENTAÇÃO TEM COMO OBJECTIVO FALAR DA MINHA EXPERIÊNCIA EM TERMOS DE RELEASE MANAGEMENT . SITUAÇÕES QUE CORRERAM BEM . SITUAÇÕES QUE CORRERAM MENOS BEM PERCEBER TAMBÉM COM VOCÊS QUAL A VOSSA ABORDAGEM EM TERMOS DE RELEASE MANAGEMENT
  • Release Management é um tema bastante complexo, pelo que um documento/apresentação é insuficiente para o cobrir na totalidade
  • RM é todo o processo de planeamento, build, teste e deploy de software
  • Garantir que existe um método consistente de deployment a ser seguido (criar linhas de orientação) Manter os vários ambientes estáveis, i.e., não introduzir erros sempre que há releases
  • Durante o suporte poderão surgir novos requisitos ou bug fixes, pelo que o ciclo irá iniciar-se!!!
  • O sistema apenas pode seguir o rasto de um ambiente de trabalho que esteja a ser gerido pela ferramenta de gestão de versões CASO ESTEJA A TRABALHAR FORA NÃO EXISTE QUALQUER VISIBILIDADE SOBRE O TRABALHO QUE O PROGRAMADOR SE ENCONTRA A EFECTUAR!!! 2. O AMBIENTE DE TRABALHO DEVERÁ MANTER-SE SEMPRE ACTUALIZADO EM RELAÇÃO ÀS VERSÕES QUE SE ENCONTRAM CHECKED IN (PRETENDE-SE TER SEMPRE A ÚLTIMA VERSÃO DOS MÓDULOS A ALTERAR, PARA NÃO EFECTUAR ALTERÇÕES SOBRE VERSÕES ERRADAS) PARECE UMA REGRA SIMPLES … MAS ACREDITEM QUE NEM SEMPRE É SEGUIDA!!! 3. NO CASO DE TERMOS A FERRAMENTA DE VC CONFIGURADA PARA EXCLUSIVE CHECK OUT => EVITA QUE OUTROS PROGRAMADORES FIQUEM BLOQUEADOS À ESPERA DO VOSSO CHECK IN CASO CONTRÁRIO => EVITA OS MERGES (ALGUM CUSTO)
  • SER ESCLARECEDOR QUANTO A REGRAS DESENVOLVIMENTO => APÓS CADA CHECK IN INTRODUZIR NO DOCUMENTO DE RELEASE A VERSÃO E O BUG FIZ ASSOCIADO BRANCHING => APENAS SE EFECTUA BRANCH SE FOR UMA NOVA “FEATURE” MAINLINE É O “TRONCO” PRINCIPAL DE CÓDIGO QUE EVOULUI “ETERNAMENTE”, I.E., É SOBRE A MAINLINE QUE SE EFECTUAM OS BRANCHES QUANDO UM BRANCH É TERMINADO E DEPLOYED É PROPAGADO NOVAMENTE PARA A MAINLINE, DE FORMA AO PRÓXIMO BRANCH SER SOBRE A “NOVA” MAINLINE O RELEASE MANAGER TEM COMO FUNÇÃO GARANTIR A CORRECTA EXECUÇÃO DO PROCESSO DE BUILD POR EXEMPLO, NOVOS MÓDULOS IMPLICAM ACTUALIZAÇÃO DO PROCESSO PARA INCLUSÃO DO MESMO GARANTIR QUE OS PROGRAMADORES PERCEBEM A IMPORTÂNCIA DO BUILD … PASSAR RESPONSABILIDADE (E.G., PAGAR SE O BUILD FALHAR)
  • . + branches => + builds, + propagação alterações, + merges . Vantagem: incluir no branch o máximo das alterações já presentes na mainline . E.g., se é criado 1 branch e depois é identificado 1 bug fix, esse branch não terá incluído esse bug fix na passagem, pelo que é inevitável 1 merge! . “branch late” mas não muito tarde, i.e., da criação desse branch não deverá estar outro desenvolvimento pendente … NESSE CASO DEVERÁ FAZER-SE O BRANCH!
  • . PRETENDE-SE GARANTIR QUE OS BUILDS SÃO IGUAIS … IMPORTANTE AQUANDO DE IDENTIFICAÇÃO DE ERROS . IDEALMENTE: 1 CHECK IN => 1 BUILD || IDEAL EM PROJECTOS: 1 VEZ POR NOIT . IMPORTANTE PARA DETECÇÃO ATENCIPADA DE ERROS . PARA SE IDENTIFICAREM OS MÓDULOS QUE FALHARAM … O ÚLTIMO BUILD COM SUCESSO … QUAIS OS FICHEIROS QUE PROVOCARAM O(S) ERRO(S) …
  • guarantee that there are no 2 developers working in the same file . NÃO TEMOS QUALQUER RESTRIÇÃO ADICIONAL
  • ATENÇÃO QUE ESTA É A NOSSA SOLUÇÃO ACTUAL, NÃO NECESSÁRIAMENTE A QUE GOSTARÍAMOS DE TER . EXEMPLO, GOSTARÍAMOS DE TER UM BUILD DA BD MAS POR QUESTÕES HISTÓRICAS DO PROJECTO ISSO NUNCA CHEGOU A SER IMPLEMENTADO . ESTAS REGRAS FORAM IMPLEMENTADAS DESDE O INÍCIO DO PROJECTO
  • . IDENTIFICAR SEMPRE OS SPs E TABELAS NOVOS COM O BUG FIX OU NOVA FEATURE ASSOCIADA . TABELA CRIADA/MODIFICADA => CÓDIGO GERADO AUTOMATICAMENTE PELO SQL SERVER
  • . IDENTIFICAR SEMPRE OS SPs E TABELAS NOVOS COM O BUG FIX OU NOVA FEATURE ASSOCIADA . TABELA CRIADA/MODIFICADA => CÓDIGO GERADO AUTOMATICAMENTE PELO SQL SERVER
  • ESTAS SÃO AS NOSSAS PRINCIPAIS REGRAS DE DESENVOLVIMENTO WEB
  • QUANDO O CICLO DE DEPLOYMENT SE PROCESSA ASSIM, COM AS REGRAS ATRÁS REFERIDAS, NÃO HÁ QUALQUER TIPO DE PROBLEMA NAS RELEASES . N PACOTES QUA -> 1 PACOTE PRD
  • HÁ DIFERENÇAS EM RELAÇÃO AO CICLO ANTERIOR, QUE VÃO IMPLICAR NÃO LINEARIDADE NO PROCESSO DE CRIAÇÃO DA RELEASE … ..
  • OS PONTOS INDICADOS A VERMELHO SÃO OS PONTOS CRÍTICOS DO PROCESSO . RAZÃO: VAI PASSAR PARA PRD APENAS O QUE FOI ACEITE PELO SPONSOR, NO ENTANTO NÃO É TUDO O QUE SE ENCONTRA EM QUA (VAI APENAS PASSAR UMA PARTE DO QUE SE ENCONTRA EM QUA)
  • . New features and bug fixes were included in the patch file if the release was in the same day . 1 RELEASE => 1 SQL PATCH Headache to decide and test what to deploy
  • Headache to decide and test what to deploy
  • NOVOS BRANCHES SÃO SEMPRE SOBRE A MAINLINE QUE TERÁ O ÚLTIMO BRANCH DEPLOYED INCLUÍDO
  • CRIAR BRANCH APENAS SE NÃO SOUBERMOS QUANDO IRÁ SER DEPLOYED PARA PRD Existem AINDA ALTERAÇÕES QUE APENAS SE ENCONTRAM EM QUA E AINDA NÃO FORAM APROVADAS PELO SPONSOR PARA PASSAR PARA PRD … PARA PODERMOS LIMPAR O CÓDIGO DAS PASSAGENS EXISTENTE
  • CRIAR BRANCH APENAS SE NÃO SOUBERMOS QUANDO IRÁ SER DEPLOYED PARA PRD Existem AINDA ALTERAÇÕES QUE APENAS SE ENCONTRAM EM QUA E AINDA NÃO FORAM APROVADAS PELO SPONSOR PARA PASSAR PARA PRD … PARA PODERMOS LIMPAR O CÓDIGO DAS PASSAGENS EXISTENTE
  • Release Management

    1. 1. <ul><li>Release Management </li></ul><ul><li>War Story </li></ul>
    2. 2. “ Release Management can be a complex topic, so any attempt to cover it in a single article would be a mistake.”, by Mike Drupeau and Sudesh Oudi ( “Release Management: Where to Start” , article)
    3. 3. Summary <ul><li>What is Release Management </li></ul><ul><li>Main Rules </li></ul><ul><li>“ On Job” examples </li></ul>
    4. 4. What is Release Management <ul><li>Planning </li></ul><ul><li>Building </li></ul><ul><li>Testing </li></ul><ul><li>Deploying </li></ul>
    5. 5. Goals <ul><li>Deployment method </li></ul><ul><li>Don’t mess stable environments </li></ul>
    6. 6. RM’s Life Cycle
    7. 7. <ul><li>Main Rules </li></ul>
    8. 8. Developers <ul><li>Do not work outside managed workspaces </li></ul><ul><li>Stay synchronized </li></ul><ul><li>Check in regularly </li></ul>
    9. 9. Release Manager <ul><li>Developing/Branching policies </li></ul><ul><li>Have a mainline </li></ul><ul><li>Control/manage build process </li></ul>
    10. 10. Branching Guidelines <ul><li>Branch only when necessary </li></ul><ul><li>Branch late </li></ul><ul><li>Branch instead of freeze </li></ul>
    11. 11. Building Guidelines <ul><li>Common Build tool </li></ul><ul><li>Build regularly </li></ul><ul><li>Keep build logs and outputs </li></ul>
    12. 12. <ul><li>“ On Job” Examples </li></ul>
    13. 13. Tools <ul><ul><li>Microsoft Visual Source Safe (VSS) </li></ul></ul><ul><ul><li>Microsoft Visual Build </li></ul></ul>
    14. 14. VSS <ul><li>Exclusive checkouts </li></ul>
    15. 15. Visual Build <ul><ul><li>Runs every night (status e-mail) </li></ul></ul><ul><ul><li>Build fails => responsible pays (increases check in responsability) </li></ul></ul><ul><ul><li>Build set to deployment folder (release manager gets the version to deploy) </li></ul></ul><ul><ul><li>Database not included </li></ul></ul>
    16. 16. Database Deployment <ul><ul><li>Patches folder (includes pending scripts file [ psf ]) </li></ul></ul><ul><ul><li>1 release => 1 SQL patch file </li></ul></ul>
    17. 17. Database Deployment <ul><ul><li>Stored Procedure (SP) [developed & tested] => SP into psf </li></ul></ul><ul><ul><li>Table created/modified => generated SQL code into psf </li></ul></ul>
    18. 18. Web Deployment <ul><li>Dev folder with all web projects </li></ul><ul><li>Deployment folder with all build projects </li></ul><ul><li>Developers only checkout projects/files in dev folder </li></ul>
    19. 19. Deployment Cycle NF – New Feature BF – Bug Fix QUA Deploy [NF1] BF1 QUA Deploy [BF1] … BF N QUA Deploy [BFN] PRD Deploy [NF1,BF1, …, BFN] NF1
    20. 20. Deployment Cycle NF – New Feature BF – Bug Fix QUA Deploy [NF1] BF1 NF2 QUA Deploy [BF1,NF2] … BF N QUA Deploy [BFN] PRD Deploy [NF1,BF1, …, BFN] NF1
    21. 21. Deployment Cycle NF – New Feature BF – Bug Fix QUA Deploy [NF1] BF1 NF2 QUA Deploy [BF1,NF2] … BF N QUA Deploy [BFN] PRD Deploy [NF1,BF1, …, BFN] NF1
    22. 22. Problems (PRD Deploy) <ul><ul><li>SQL patches with comments </li></ul></ul><ul><ul><ul><li>e.g., new columns on table </li></ul></ul></ul><ul><ul><ul><ul><li>1 release => 1 SQL patch </li></ul></ul></ul></ul>
    23. 23. Problems (PRD Deploy) <ul><ul><li>Web projects with comments </li></ul></ul><ul><ul><ul><li>e.g., methods with new parameters </li></ul></ul></ul><ul><ul><li>Web projects (Back Office) with comments </li></ul></ul><ul><ul><ul><li>e.g., new textbox </li></ul></ul></ul>
    24. 24. New Deploy Decisions <ul><li>Release Management excel file </li></ul><ul><li>Database </li></ul><ul><ul><li>1 new feature/bug fix => 1 patch file </li></ul></ul><ul><ul><li>SP signature modification =>SP name change (to avoid unnecessary propagation) </li></ul></ul>
    25. 25. New Deploy Decisions <ul><li>Web project </li></ul><ul><ul><li>New feature => new branch (branch only when it’s necessary) </li></ul></ul><ul><ul><li>Method signature modification => method name change </li></ul></ul>
    26. 26. New Deploy Decisions <ul><li>Release Manager </li></ul><ul><ul><li>Only deploys in PRD accepted SQL patches </li></ul></ul><ul><ul><li>Branch deployed => merge with the dev folder version </li></ul></ul><ul><ul><li>MUCH MORE WORK TO DO, BUT LESS RISK </li></ul></ul>
    27. 27. Today’s Problems <ul><li>Decide when to branch </li></ul><ul><li>Release Manager merging when deploying (too costly) </li></ul><ul><li>Still waiting to clean the code when the problems appeared </li></ul>
    28. 28. Your War Story <ul><li>… </li></ul>
    29. 29. Q&A
    30. 30. References <ul><li>Wikipedia </li></ul><ul><li>“ 7 Ways to Improve Your Software Release Management ” </li></ul><ul><li>Release Management ( Becta ) </li></ul><ul><li>“ Release Management : Where to Start ?” </li></ul>
    31. 31. The end

    ×