Atividade:
| ||||||||||||||||
Finalidade
|
|
| Passos | |
| Artefatos Informados: | Artefatos Resultantes: |
| Freqüência: Contínua | |
| Papel: Todos os Papéis | |
| Mentor de Ferramentas: | |
| Detalhamentos do Fluxo de Trabalho: |
O termo 'liberação' transmite a noção da integração de trabalho de uma série de implementadores. Sendo assim, a liberação é um passo importante e uma 'barreira de qualidade' de revisões e aprovações que precisa ser transposta para que o trabalho possa ser aceito em uma 'área de encenação' de nível superior.
Uma boa política de projeto é exigir que os desenvolvedores reformulem seus espaços de trabalho de desenvolvimento de acordo com a baseline recomendada atual do projeto, antes de aceitar o trabalho no espaço de trabalho de integração. A meta dessa política é fazer com que os desenvolvedores criem e testem seu trabalho nas áreas de desenvolvimento, com base no trabalho incluído nas baselines estáveis mais recentes, antes de liberá-lo para o espaço de trabalho de integração. Essa prática minimiza a quantidade de mesclagem que os desenvolvedores devem fazer ao executar as operações de liberação.
Outra boa política de projeto é assegurar que todos os arquivos serão submetidos a check-in antes da liberação. Isso evitará que haja arquivos órfãos não incluídos em um build e que venham a ser necessários em atualizações subseqüentes.
A liberação é um passo importante que parte do pressuposto de que um desenvolvedor considera seu trabalho com qualidade suficiente para ser incorporado ao produto geral.
Ela deve fazer parte da política de projeto que determina quem deve revisar determinados artefatos e qual nível de qualidade esses artefatos atingiram antes de serem aceitos pelos outros membros da equipe do projeto. Algumas orientações sobre revisões são fornecidas em Orientações de Trabalho: Revisões. Vários artefatos do Rational Unified Process possuem 'pontos de verificação' associados que podem ser usados para avaliar a qualidade de determinados artefatos. Por exemplo, se um artefato for considerado deficiente em mais de um determinado número de pontos de verificação, ele será submetido a um novo trabalho e, desse modo, não estará qualificado para 'promoção'.
Uma política de projeto comum é exigir que o desenvolvedor mescle suas mudanças com as efetuadas por outros desenvolvedores. Isso é feito geralmente em um espaço de trabalho de integração privado, a fim de que as mudanças mescladas possam ser testadas antes da liberação final para o espaço de trabalho de integração do projeto. A liberação é concluída quando todas as mudanças de mesclagem foram submetidas a check-in e liberadas.
Atualize o status da ordem de trabalho (por exemplo, defina como "Concluído" caso todo o trabalho tenha sido feito) conforme definido pelo Plano de Gerenciamento de Configuração do projeto.
|
Rational Unified Process
|
