![[object Object],[object Object]](https://image.slidesharecdn.com/releasemanagement-12622714607967-phpapp01/85/release-management-1-320.jpg)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Release Management
Ähnlich wie Release Management (20)
Release Management
- 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)
- 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. 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. 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
- 29. Q&A
- 31. The end
Hinweis der Redaktion
- 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