Usando um modelo de processo de criação do TFS (fluxo de trabalho) para implantação

Estou pensando em usar fluxos de trabalho do TFS Build para implantações complexas. Temos alguns que podem precisar implantar:

Aplicativos e serviços da Web
Base de dados
Relatórios do SSRS
Pacotes SSIS
Quem sabe o que mais

Gosto do fato de poder fornecer ao fluxo de trabalho alguns parâmetros básicos, como qual build implantar e que seria executado. Potencialmente, algumas partes podem precisar de aprovação humana, e eu sei que o fluxo de trabalho também pode lidar com isso. Um exemplo é que podemos usar o fluxo de trabalho para criar um script de alteração de nossos projetos de banco de dados do Visual Studio, mas o grupo DBA desejará aprovar o script antes de executá-lo.

Estou interessado em saber se outras pessoas usaram "builds" para isso no passado e quais problemas foram encontrados.

— John Saunders
fonte

Estamos usando o TFS 2010 para gerenciar nossas construções / implantações. Não tenho respostas rápidas para você; mas, à medida que surgem problemas, sinta-se à vontade para me enviar um e-mail e podemos pelo menos tentar descobrir.

— Stephen Gross

Usamos o TFS para acionar nossas compilações, mas usamos o msbuild para compilar nossos projetos. A principal vantagem é que temos um script de construção que pode alterar e manter um controle de versão. O problema é com os fluxos de trabalho, por exemplo: como você criará uma versão mais antiga do seu projeto? Com um script de construção, você obtém a versão mais antiga do controle de origem e pronto. Também é bom poder mexer com ele e ativar / desativar diferentes opções.

Se você tem certeza de que possui um ciclo de construção fixo, provavelmente poderá realizá-lo, caso contrário, ter um script é provavelmente a opção mais segura e mais fácil de usar.

— Carlo Kuip
fonte

Os fluxos de trabalho são arquivos .xaml armazenados no controle de origem. Vou precisar de um processo que ramifique os arquivos .xaml junto com o código-fonte. Sem dúvida, você ramifica seus arquivos msbuild junto com a fonte.

— John Saunders

@JohnSaunders sim, nós ramificamos nossos scripts de construção. É legal que a configuração do seu fluxo de trabalho seja armazenada em um arquivo xml, mas que influência a alteração da configuração tem nos itens que estão em uma versão diferente do seu fluxo de trabalho (itens de trabalho, tarefas etc. no seu projeto também estão no mesmo fluxo de trabalho, certo? ) É aí que vejo um risco, alterando o comportamento de como o TFS lida com o seu projeto em tempo real.

— Carlo Kuip

Eu não sei o que você quer dizer. Alterar o modelo do processo de construção não altera os itens de trabalho. O que você quer dizer com "itens que estão em uma versão diferente do seu fluxo de trabalho"?

— John Saunders

O modelo de processo que você aplica ao criar um projeto TFS está criando um fluxo de trabalho. Isso significa que, se você criar um item de trabalho, ele estará vinculado aos vários estágios desse fluxo de trabalho. Seus processos de compilação serão uma extensão desse fluxo de trabalho ou serão separados?

— Carlo Kuip

Desculpe, você está confundindo um modelo de processo e um modelo de processo de compilação. A Microsoft escolheu mal seus termos. Além disso, o modelo de processo que você usa ao criar um projeto de equipe cria um fluxo de trabalho que eu conheço.

— John Saunders