|
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 entrega.
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 produtos de trabalho e qual
nível de qualidade esses produtos de trabalho atingiram antes de serem aceitos para uso pelos outros membros da equipe
do projeto. Algumas orientações sobre revisões são fornecidas na Técnica: Revisões.
Muitos dos produtos de trabalho no RUP (Rational Unified Process) possuem uma 'lista de verificação' associada
que pode ser utilizada para avaliar a qualidade desse produto de trabalho. Por exemplo, se um produto de trabalho 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'.
|
