Visão geral do Classic Delivery Pipeline

DevOps Insights chegará ao fim de sua vida útil e será descontinuado em 31 de agosto de 2026. O serviço Continuous Delivery será descontinuado nas seguintes regiões em 12 de fevereiro de 2027: au-syd, ca-tor, us-east. O Code Risk Analyzer também será descontinuado em todas as regiões nessa data. Se uma região não apresentar uso ativo desses recursos, os recursos nessa região poderão ser descontinuados mais cedo e deixar de aceitar novas instâncias. Saiba mais

O IBM Cloud® Continuous Delivery inclui o Classic Delivery Pipeline para construir, testar e implementar em um modo de repetição com mínima intervenção humana. Em um pipeline, as sequências de estágios recuperam a entrada e executam tarefas, como construções, testes e implementações.

Você pode trabalhar com os pipelines de entrega Classic e Tekton usando o navegador ou usando o IBM Cloud Comandos CLI Developer Tools(ibmcloud dev). Você também pode trabalhar com pipelines de entrega do Tekton usando a API e os HTTP SDKs do pipeline do Tekton ou usando o provedor IBM Cloud Terraform. Para obter mais informações sobre os pipelines de entrega do Tekton, consulte “Trabalhando com pipelines do Tekton ”.

As suas permissões para visualizar, modificar ou executar um pipeline são baseadas no controle de acesso para a cadeia de ferramentas que possui o pipeline. Para obter mais informações sobre o controle de acesso para as cadeias de ferramentas, consulte Gerenciando o acesso às cadeias de ferramentas em grupos de recursos.

É possível especificar os scripts a serem executados em muitos dos tipos de tarefas que são fornecidos pelo pipeline, fornecendo controle direto sobre o que é executado pela tarefa. Esses scripts são executados em uma imagem do Docker que contém uma série de ferramentas de desenvolvimento padrão, incluindo ferramentas que são necessárias para interagir com os tempos de execução do IBM Cloud. Para obter mais informações sobre o que a imagem padrão do Docker contém, veja Recursos pré-instalados. Se a sua tarefa requer ferramentas de desenvolvimento que não estão disponíveis na imagem padrão ou se você precisa de versões diferentes dessas ferramentas, é possível usar uma imagem customizada. Para obter mais informações sobre imagens customizadas, veja Trabalhando com imagens customizadas do Docker.

Quando o pipeline executa scripts, as propriedades que descrevem o contexto em que a tarefa está em execução são passadas para o script usando variáveis de ambiente. Por exemplo, a URL do repositório que é a entrada para o estágio, o nome do estágio e a tarefa que está sendo executada, os parâmetros especificados pelo tipo de tarefa e assim por diante. Para visualizar uma lista de variáveis de ambiente disponíveis, veja Recursos pré-instalados.

É possível definir propriedades no nível de pipeline e no nível de estágio. As propriedades de pipeline são compartilhadas em todos os estágios e tarefas em um pipeline. As propriedades do estágio são exclusivas para um estágio específico e compartilhadas em todas as tarefas nesse estágio. Para obter mais informações sobre as propriedades, veja Propriedades do ambiente (variáveis de ambiente).

Estágios

Os estágios organizam a entrada e as tarefas conforme o código é construído, implementado e testado. Os estágios aceitam entrada de repositórios de controle de origem (repositórios SCM) ou de tarefas de construção em outros estágios. Para os repositórios SCM, a entrada são os conteúdos de uma ramificação específica no repositório; para as tarefas de construção, a entrada são os artefatos produzidos pela tarefa. Quando você cria seu primeiro estágio, a guia ENTRADA contém configurações padrão.

Quando um estágio é executado, a entrada dele é passada para cada uma das tarefas nele. Cada tarefa recebe um contêiner limpo no qual executar. Como resultado, as tarefas em um estágio não podem passar artefatos umas para as outras. Para passar artefatos nas tarefas, separe-as em dois estágios e use a saída da tarefa no primeiro estágio como entrada para o segundo estágio. Qualquer tarefa de construção pode ser passada como entrada para qualquer outra tarefa em outro estágio. Por padrão, a saída é criada na pasta ./. Caso você não deseje saídas de uma tarefa de construção, configure uma pasta como a saída e não envie nenhuma saída para ela.

De maneira semelhante a como é possível definir propriedades de pipeline, também é possível definir propriedades de estágio para uso em todas as tarefas em um estágio específico. Por exemplo, é possível definir uma propriedade TEST_URL que passa uma URL para as tarefas de implementação e teste em um estágio. A tarefa de implementação implementa nessa URL e a tarefa de teste testa o app em execução na URL. As propriedades do estágio também são passadas para os scripts de tarefa usando variáveis de ambiente. Se a mesma propriedade for definida no nível de pipeline e no nível de estágio, o valor da propriedade do estágio será usado.

Por padrão, em um estágio, as construções e implementações são executadas automaticamente toda vez que mudanças são entregues no repositório SCM de um projeto. Os estágios e as tarefas são executados em série; eles ativam o controle de fluxo para seu trabalho. Por exemplo, você poderá colocar um estágio de teste antes de um estágio de implementação. Se os testes no estágio de teste falharem, o estágio de implementação não será executado.

O Delivery Pipeline usa trabalhadores públicos e privados para executar as tarefas em um estágio. Por padrão, as tarefas de pipeline são executadas usando trabalhadores públicos na infraestrutura compartilhada pública gerenciada pela IBM.

Em certos cenários, seu Delivery Pipeline pode requerer acesso a recursos internos ou no local. Nessas situações, é possível conectar e integrar um Delivery Pipeline Private Worker para executar em sua própria infraestrutura do Kubernetes.

Você talvez queira restringir o controle de um estágio específico. Se você não quiser que um estágio seja executado toda vez que uma mudança ocorrer na sua entrada, será possível desativar o recurso. Na guia ENTRADA, na seção Acionador de estágio, clique em Executar tarefas somente quando este estágio for executado manualmente.

Mais opções de acionador de estágio estão disponíveis para estágios que usam o tipo de entrada de repositório Git. Por exemplo, é possível optar por executar tarefas automaticamente para eventos do Git na ramificação escolhida. Ao escolher esse tipo de acionador, deve-se selecionar um ou mais dos tipos de eventos a seguir:

Quando uma confirmação é enviada por push é acionado quando um push é feito para a ramificação de repositório selecionada.
Quando uma solicitação pull/mesclagem é aberta ou atualizada é acionado quando uma solicitação pull ou uma solicitação de mesclagem é aberta ou editada.
Quando uma solicitação pull/mesclagem é fechada é acionado quando uma solicitação pull ou uma solicitação de mesclagem é fechada, mesmo sem uma confirmação associada.

Se você marcar a caixa de seleção Quando uma solicitação de mesclagem/pull é aberta ou atualizada, o status do pipeline será retornado para o repositório Git. Quando uma solicitação pull ou uma solicitação de mesclagem aciona seu pipeline, uma verificação de status sequencial é exibida na página. Uma verificação de status é exibida para cada um dos estágios que são executados em seu pipeline e os links para os logs e o histórico para cada estágio são fornecidos. Conforme a verificação de status é executada, ela é atualizada de pendente para bem-sucedida ou com falha. Se seu pipeline contiver múltiplos estágios, cada estágio relatará seu status na lista de verificação.

Esse feedback de status também é suportado pela ferramenta GitLab Community Edition hospedada pela IBM para solicitações de mesclagem.

Também é possível restringir a mesclagem com base nos resultados das verificações de status usando regras de proteção de ramificação do Git. Após uma regra de proteção de ramificação ser criada, toda a mesclagem será bloqueada até que todas as verificações de status necessárias sejam bem-sucedidas.

Solicitações pull do Bitbucket Cloud

O Bitbucket Cloud não suporta atualmente referências de repositório para solicitações pull, o que é necessário para o serviço Continuous Delivery. Esse recurso permite que solicitações pull sejam enviadas ao repositório que você deseja acessar usando referências no formato a seguir: refs/pull/123/…

Você pode baixar e fazer o check-out de uma solicitação de pull localmente usando o repositório de código-fonte URL. Entretanto, se o repositório de origem for um repositório bifurcado privado, o serviço Continuous Delivery não terá o acesso necessário para gerenciar solicitações pull. Para realizar uma solução alternativa para essa limitação, deve-se fornecer explicitamente o acesso necessário ao repositório bifurcado no script de pipeline.

No script de pipeline de bash de amostra a seguir, dois usuários estão usando o Bitbucket Cloud e cada um deles tem uma bifurcação privada de seu repositório principal (bitbucket.org/userA/repo-forked-A e bitbucket.org/userB/repo-forked-B). O script é configurado para conferir a solicitação pull quando uma tarefa de construção é acionada por um evento aberto de solicitação pull ou um evento de atualização de um dos dois repositórios bifurcados.

case "$BITBUCKET_PR_SOURCE_HOST" in       #BITBUCKET_PR_SOURCE_HOST is an environment exported by pipeline if job is triggered by a bitbucket pull request
  *userA*)                                #userA should be replaced to anything to identify a forked repo's url
    url="https://$username:$password@$BITBUCKET_PR_SOURCE_HOST"    #you need to provide username and password for repo-forked-A
    ;;
  *userB/repo-forked-B*)                  #userB/repo-forked-B should be replaced to anything to identify a forked repo's url
    url="https://$username1:password1@$BITBUCKET_PR_SOURCE_HOST"   #you need to provide username1 and password1 for repo-forked-B
    ;;
esac
git fetch $url $BITBUCKET_PR_SOURCE_BRANCH   #BITBUCKET_PR_SOURCE_BRANCH is an environment exported by pipeline if job is triggered by a bitbucket pull request
git checkout FETCH_HEAD

Estágio Build

O estágio de Construção especifica um Tipo Builder para indicar como construir os artefatos.

Muitos dos campos que estão disponíveis em tarefas de Construção são comuns em múltiplos tipos de Construtor.

Os tipos de Builder a seguir estão disponíveis:

Tipos de construtores
Tipo de construtor	Descrição	Tipos de tarefa suportados
Simples	Arquiva a entrada do estágio atual sem modificação para uso por estágios futuros. Geralmente, esse tipo de construtor é útil apenas quando a entrada do estágio é de um repositório SCM.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente.
Ant	Usa arquivos Apache Ant para gerenciar a tarefa de construção.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Registro de contêiner	Constrói imagens do Docker e as transfere por upload para o IBM Cloud Container Registry.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Chave de API: a chave da API do IBM Cloud a ser usada para fornecer permissões para recursos da conta. Namespace do Container Registry: o namespace no qual se deseja armazenar a imagem de construção. Nome da imagem do Docker: o nome da imagem que é construída e transferida por upload para o IBM Cloud Container Registry por meio desta tarefa. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Imagem customizada do Docker	Realiza compilações utilizando sua imagem personalizada do Docker, com controle detalhado sobre as versões do Node.js, do Java™ ou de outras ferramentas.	Nome da imagem do Docker: o nome da imagem que essa tarefa constrói e transfere por upload para o IBM Cloud Container Registry. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso em um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Gradle	Constrói usando o Gradle.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção - especifica o diretório que contém a saída da tarefa a ser arquivada para uso em um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Grunt	Constrói usando o Grunt.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Maven	Constrói usando o Apache Maven.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
npm	Instala dependências com o gerenciador de pacote do Nó.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Shell script	Executa um shell script do UNIX, como o Bash.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Script de construção: executado em um novo shell do Ubuntu sempre que a tarefa é executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente. Ativar repositório de teste: marque esta caixa de seleção para especificar que a tarefa de construção executa testes que produzem arquivos de resultado no formato XML do JUnit. Um relatório baseado nos arquivos de resultado é exibido na guia Testes da página Resultados da tarefa. Se algum teste falhar, a tarefa será marcada como com falha. Ativar relatório de cobertura de código: marque esta caixa de seleção para mostrar campos adicionais que podem ser usados para o relatório de cobertura de código. É possível especificar o executador de cobertura (como o JaCoCo, e o Cobertura), a localização do arquivo de resultados da cobertura e o diretório de resultados da cobertura, em relação ao diretório de trabalho.
Gradle (Artifactory, Nexus ou SonarQube)	Constrói e implementa usando o Gradle com um repositório do Nexus ou do Artifactory. O Gradle também se integra ao SonarQube.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Instância de integração da ferramenta de repositório: o nome da instância de integração da ferramenta de repositório a ser usada para esta tarefa de construção. Tipo de integração da ferramenta de repositório: o tipo da integração de ferramenta a partir da qual obter informações do Gradle. Instância de integração do SonarQube: o nome da instância de integração do SonarQube a ser usada com esta tarefa de construção. Comando de construção: o comando de construção a ser executado sempre que a tarefa for executada. No campo Script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente.
Maven (Artifactory, Nexus or SonarQube)	Constrói e implementa usando o Maven com um repositório do Nexus ou do Artifactory. O Maven também se integra ao SonarQube.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Instância de integração da ferramenta de repositório: nome da instância de integração da ferramenta de repositório a ser usada com esta tarefa de construção. Tipo de integração da ferramenta de repositório: o tipo da integração de ferramenta a partir da qual obter informações do Gradle. Instância de integração do SonarQube: o nome da instância de integração do SonarQube a ser usada com esta tarefa de construção. Comando de construção: o comando de construção a ser executado sempre que a tarefa for executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente.
npm (Artifactory ou Nexus)	Constrói usando o npm com um repositório do Nexus ou do Artifactory.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Instância de integração da ferramenta de repositório: o nome da instância de integração da ferramenta de repositório a ser usada para esta tarefa de construção. Tipo de integração da ferramenta de repositório: o tipo da integração de ferramenta a partir da qual obter informações do Gradle. Instância de integração do SonarQube: o nome da instância de integração do SonarQube a ser usada com esta tarefa de construção. Comando de construção: o comando de construção a ser executado sempre que a tarefa for executada. No campo Script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Versão do módulo de captura instantânea de incremento: oferece suporte à entrega contínua, incrementando localmente a versão do módulo, com base no conteúdo do arquivo `package.json` e na captura instantânea atual relatada no registro npm na etapa de publicação. Diretório ativo: especifica o diretório no qual o script é executado. Diretório do archive de construção: especifica o diretório que contém a saída da tarefa a ser arquivada para uso um estágio subsequente.

Estágio de Implementação

O estágio de Implementação especifica a entrada de um estágio de Construção. As tarefas no estágio de implementação especificam um Tipo Deployer. Os tipos de Deployer a seguir estão disponíveis:

Tipos de implementadores
Tipo de implementador	Descrição	Tipos de tarefa suportados
Imagem customizada do Docker	Realiza a implantação utilizando sua imagem personalizada do Docker, com controle detalhado sobre as versões do Node, Java™ ou outras ferramentas.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Chave de API: a chave da API do IBM Cloud a ser usada para fornecer permissões para recursos da conta. Docker nome da imagem: O nome da imagem que este trabalho cria e envia para o. IBM Cloud Container Registry Script de implementação: o comando de implementação a ser executado sempre que a tarefa for executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto.
Kubernetes	Implementa aplicativos em clusters Kubernetes, como aqueles localizados no IBM Cloud Container Service.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Chave de API: a chave da API do IBM Cloud a ser usada para fornecer permissões para recursos da conta. Nome do cluster: nome do cluster Kubernetes; a plataforma na qual os componentes do Kubernetes são implementados. Script de implementação: o comando de implementação a ser executado sempre que a tarefa for executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto.

Estágio do teste

O estágio do teste especifica a configuração de teste. As tarefas no estágio do teste especificam um Tipo de testador. Os tipos de testador a seguir estão disponíveis:

Tipos de testadores
Tipo de testador	Descrição	Tipos de tarefa suportados
Simples	Ativa um comando shell para executar os testes automatizados com um relatório de teste opcional.	Versão de imagem do pipeline: não usada. Script de teste: comando de teste a ser executado sempre que a tarefa for executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: o diretório no qual o script de teste é executado. Ativar relatório de teste: não usado. Ativar relatório de cobertura de código: não utilizado.
Imagem customizada do Docker	Realize testes utilizando sua imagem personalizada do Docker com controle detalhado sobre as versões do Node, Java™ ou outras ferramentas.	Nome da imagem do Docker: o nome da imagem do Docker com o qual executar a tarefa. Para ter certeza de que suas tarefas sejam executadas em um contexto limpo, execute-as em contêineres do Docker. Script de teste: comando de teste a ser executado sempre que a tarefa for executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: o diretório no qual o script de teste é executado. Ativar relatório de teste: não usado. Ativar relatório de cobertura de código: não utilizado.
Vulnerability Advisor	Executa uma verificação de conformidade e de vulnerabilidade na imagem especificada e exibe os resultados. Se algum problema for localizado, esse estágio falhará.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Chave de API: a chave da API do IBM Cloud a ser usada para fornecer permissões para recursos da conta. Namespace do Container Registry: o namespace no qual a imagem de construção está armazenada. Nome da imagem do Docker: o nome da imagem do Docker com a qual executar a tarefa. Para ter certeza de que suas tarefas sejam executadas em um contexto limpo, execute-as em contêineres do Docker. Tag da imagem do Docker: uma tag da imagem do Docker que é exibida no IBM Cloud Container Registry. Script de teste: comando de teste a ser executado sempre que a tarefa for executada. No campo de script, insira um script ou scripts de referência que estejam armazenados no controle de origem do seu projeto. Diretório ativo: o diretório no qual o script de teste é executado. Ativar relatório de teste: não usado. Ativar relatório de cobertura de código: não utilizado.
Sauce Labs	Executa testes em JavaScript,, Node ou Java™ usando o Sauce Labs.	Versão de imagem do pipeline: é executada em um contêiner usando uma imagem integrada do Docker que fornece vários comandos integrados. Para adotar versões mais recentes desses comandos, use uma versão de imagem mais recente. Instância de serviço: selecione uma instância de configuração ou crie uma.

Tipos de tarefas descontinuadas

Vários tipos de tarefas, como a tarefa de compilação “ IBM Globalization Pipeline ”, a tarefa de teste “Space Shell” e a tarefa de teste “ DevOps Insights Gate”, foram descontinuadas. Embora esses tipos de tarefas tenham sido descontinuados, talvez ainda seja possível carregá-los na IU, com um indicador de que o tipo de tarefa foi descontinuado. Como alternativa, é possível que a tarefa seja revertida para outro tipo de tarefa ainda suportada, com uma notificação de aviso.

Caso seja necessário usar a configuração de um tipo de tarefa descontinuada, use um dos métodos a seguir para acessar a configuração do pipeline.

Usar a Devtool do IBM Cloud:

ic dev pipeline-get 7325f511-492a-4c35-a388-5e499e65d6bb -output JSON

Use a API do Delivery Pipeline:

curl --location --request GET 'https://devops-api.us-south.devops.cloud.ibm.com/v1/pipeline/pipelines/7325f511-492a-4c35-a388-5e499e65d6bb/stages' \
--header 'Authorization: Bearer <IAM Bearer token>

Na guia Rede da IU do Delivery Pipeline, faça a filtragem com base no ID do pipeline para localizar o pipeline que contém os dados de tipo da tarefa descontinuada.

Chaves de API

Algumas das tarefas padrão do Pipeline utilizam chaves de API d IBM Cloud para acessar serviços, como a implantação em Kubernetes. O serviço IBM Cloud Identity and Access Management (IAM) fornece dois tipos de chaves de API:

chaves de API do usuário: essas chaves de API fornecem acesso total a todos os serviços e recursos aos quais o usuário tem acesso.
chaves de API de serviço: é possível configurar chaves de API de serviço para fornecer acesso específico a vários serviços e recursos.

Alguns serviços não podem utilizar chaves API de ID de serviço. Nesses casos, a interface com o usuário do pipeline solicita que você especifique uma chave de API do usuário.

Como as tarefas de pipeline executam scripts criados pelo usuário que podem usar chaves de API de serviço de maneiras arbitrárias, o pipeline não pode determinar o conjunto de restrições a serem aplicadas a uma chave específica. Nesses casos, se você solicitar que o pipeline crie uma chave de API, ele criará uma chave de API do usuário. Para manter a segurança forte, como alternativa, use uma chave de API de serviço com acesso restrito a apenas os serviços e recursos que você precisa no script. Nessa instância, você mesmo deve criar a chave de API. Para obter mais informações sobre como criar uma chave de API, consulte Chaves de API da IBM Cloud.

Tarefas

Uma tarefa é uma unidade de execução dentro de um estágio. Um estágio contém diversas tarefas e as tarefas de um estágio são executadas sequencialmente. Por padrão, se uma tarefa falhar, as tarefas subsequentes do estágio não serão executadas.

Criar e testar trabalhos em um — e testar trabalhos em um

Tarefas executadas em diretórios ativos discretos dentro dos contêineres do Docker que são criados para cada pipeline executado. Antes da execução de uma tarefa, seu diretório ativo é preenchido com a entrada que é definida no nível do estágio. Por exemplo, talvez você tenha um estágio que contém uma tarefa de teste e uma tarefa de implementação. Se você instalar dependências de uma tarefa, elas não estarão disponíveis à outra tarefa. Entretanto, se você tornar as dependências disponíveis na entrada do estágio, elas estarão disponíveis a ambas as tarefas.

Exceto tarefas de construção do tipo simples, ao configurar uma tarefa, é possível incluir shell scripts do UNIX que incluam comandos de construção, teste ou implementação. Como as tarefas são executadas em contêineres ad hoc, as ações de uma não podem afetar os ambientes de execução das outras, mesmo que essas tarefas façam parte do mesmo estágio.

É possível encontrar exemplos de scripts de compilação e implantação em https://github.com/open-toolchain/commons.

Além disso, as tarefas de pipeline podem executar apenas os comandos a seguir como sudo:

/usr/sbin/service
/usr/bin/apt-get
/usr/bin/apt-key
/usr/bin/dpkg
/usr/bin/add-apt-repository
/opt/IBM/node-v0.10.40-linux-x64/npm
/opt/IBM/node-v0.12.7-linux-x64/npm
/opt/IBM/node-v4.2.2-linux-x64/npm
/usr/bin/Xvfb
/usr/bin/pip

Após a execução de uma tarefa, o contêiner que foi criado para ela é descartado. Os resultados da execução de uma tarefa podem persistir, mas o ambiente no qual ela foi executada não.

As tarefas podem ser executadas por até 60 minutos. Quando as tarefas excedem esse limite, elas falham. Se uma tarefa estiver excedendo o limite, divida-a em várias tarefas. Por exemplo, se uma tarefa executar três trabalhos, você poderá dividi-la em três tarefas: uma para cada trabalho.

Para saber como incluir uma tarefa em um estágio, veja Incluindo uma tarefa em um estágio.

Tarefas de construção

As tarefas de construção compilam seu projeto em preparação para implementação. Elas geram artefatos que podem ser enviados para um diretório de archive de construção, embora por padrão, os artefatos sejam colocados no diretório-raiz do projeto.

As tarefas que tomam a entrada das tarefas de construção devem referenciar os artefatos de construção na mesma estrutura em que eles foram criados. Por exemplo, se uma tarefa de construção arquivar artefatos de construção em um diretório output, um script de implementação consultaria o diretório output em vez do diretório-raiz do projeto para implementar o projeto compilado. É possível especificar o diretório para archive inserindo o nome do diretório no campo Construir diretório de archive. Deixar o campo em branco, arquiva o diretório raiz.

Se você usar o tipo de construtor Simples, o seu código não será compilado nem construído; ele será empacotado e disponibilizado para os estágios futuros.

Tarefas de implementação

As tarefas de implementação fazem upload do seu projeto para o IBM Cloud como um app e são acessíveis por meio de uma URL. Depois que um projeto é implementado, é possível localizar o app implementado no seu painel do IBM Cloud.

As tarefas de implementação podem implementar novos apps ou atualizar os existentes. Mesmo se você primeiro implementou um app usando outro método, será possível atualizar o app usando uma tarefa de implementação. Para atualizar um app, na tarefa de implementação, use o nome desse app.

É possível implementar para uma ou várias regiões e serviços. Por exemplo, é possível configurar seu Delivery Pipeline para usar um ou mais serviços, testar em uma região e implementar para produção em múltiplas regiões.

Tarefas de teste

Para requerer que as condições sejam atendidas, inclua tarefas de teste antes ou após suas tarefas de construção e implementação. É possível customizar as tarefas de teste para serem simples ou complexas, conforme necessário. Por exemplo, você poderá emitir um comando cURL e esperar uma resposta específica. Também será possível executar um conjunto de testes de unidade ou executar testes funcionais com serviços de teste de terceiros, como o Sauce Labs.

Se os seus testes produzirem arquivos de resultado no formato XML JUnit, um relatório baseado nos arquivos de resultado será mostrado na guia Testes de cada página de resultado do teste. Se um teste falhar, a tarefa também falhará.

Propriedades do ambiente (variáveis de ambiente)

Um conjunto de propriedades do ambiente predefinidas fornece acesso a informações sobre o ambiente de execução da tarefa. Para obter uma lista completa das propriedades do ambiente predefinidas, veja Propriedades e recursos do ambiente.

Também é possível definir suas próprias propriedades do ambiente. Por exemplo, você pode definir uma propriedade API_KEY que passa uma chave de API que é usada para acessar recursos do IBM Cloud por todos os scripts no pipeline.

É possível incluir os tipos de propriedades a seguir:

Texto: uma chave de propriedade com um valor de linha única.
Área de texto: uma chave de propriedade com um valor multilinhas. Uma versão base64 de cada valor da propriedade da área de texto também está disponível. É possível acessar essa versão usando o nome da chave da propriedade com um sufixo _base641 no final. É possível decodificar a versão Base64 de uma propriedade Área de texto e repeti-la digitando echo "$(echo $multi_base64 | base64 -d)", em que multi é o nome da chave da propriedade definido e multi_base64 é a propriedade adicional fornecida. A imagem base do pipeline contém suporte integrado para gerenciar a codificação multilinhas de forma transparente. No entanto, ao usar uma imagem customizada, deve-se anexar a propriedade do sufixo _base64 para evitar problemas onde o seu valor é truncado por um final de linha.
Seguro: uma chave da propriedade com um valor de linha única que é protegida com criptografia AES-128. O valor é exibido como asteriscos.
Propriedades: um arquivo no repositório do projeto. Esse arquivo pode conter diversas propriedades. Cada propriedade deve estar em sua própria linha. Para separar os pares de valores de chaves, use o sinal de igual (=). Coloque todos os valores da sequência entre aspas. Por exemplo, MY_STRING="SOME STRING VALUE".

É possível examinar as propriedades do ambiente para uma tarefa de pipeline executando o comando env no script da tarefa.

Propriedades de pipeline

Para definir propriedades de pipeline, no menu overflow na página Pipeline, selecione Configurar pipeline.

Na guia PROPRIEDADES DO AMBIENTE na página de configuração de Pipeline, configure as propriedades do ambiente de nível de pipeline.

Página de propriedades do — de propriedades do

propriedades do estágio

Para definir as propriedades do estágio, abra a página Configuração de estágio e clique na guia PROPRIEDADES DO AMBIENTE.

É possível definir uma propriedade de estágio usando um valor inicial (ou um valor em branco) e, em seguida, substituindo esse valor em uma tarefa exportando uma variável de ambiente. Ao substituir o valor inicial, tarefas subsequentes no estágio poderão ver o novo valor. Por exemplo, é possível incluir o comando a seguir para configurar a propriedade $API_KEY e disponibilizá-la para outra tarefa no estágio: export API_KEY=<insert API key here>

Propriedades calculadas

É possível calcular os valores da propriedade do ambiente que são compartilhados entre os estágios criando um arquivo build.properties enquanto o estágio está em execução e, então, deixar que o próximo estágio execute o arquivo. Por exemplo, sua tarefa de construção pode incluir o comando a seguir no script de construção:

echo "IMAGE_NAME=${FULL_REPOSITORY_NAME}" >> $ARCHIVE_DIR/build.properties

Todas as tarefas iniciam executando o arquivo build.properties, caso ele exista.

Criando e utilizando artefatos

As tarefas de construção buscam automaticamente o conteúdo na pasta atual na qual o script do usuário é executado. Se você não precisar de todo o conteúdo do repositório git para implementação posterior, será preferível que configure um diretório de saída explícito e, em seguida, copie ou crie os artefatos relevantes nesse local. Os scripts da tarefa são executados no resultado de construção (diretório de saída).

As tarefas de implementação que implementam no IBM Cloud Kubernetes Service precisam especificar a chave de API da Plataforma de um usuário sob cuja autoridade as tarefas são executadas, um Dockerfile e, opcionalmente, um gráfico do Helm.

O script da tarefa é executado após a tarefa ter efetuado login no ambiente de destino usando a chave de API da Plataforma designada a ela (para que seja possível executar os comandos cf push ou kubectl no script).

Um pipeline de exemplo

Um pipeline simples pode conter três estágios:

Um estágio de construção que compila e executa processos de construção em um app.
Um estágio de teste que implementa uma instância do app e, em seguida, executa testes nele.
Um estágio de produção que implementa uma instância de produção do app testado.

Esse pipeline é mostrado no diagrama conceitual a seguir:

Um diagrama conceitual de estágios e trabalhos em um pipeline*Modelo — de um pipeline de três

Os estágios tomam suas entradas dos repositórios e das tarefas de construção e as tarefas dentro de um estágio são executadas de maneira sequencial e independente umas das outras. No pipeline de exemplo, os estágios são executados sequencialmente, mesmo que os estágios de Teste e Produção assumam a saída do estágio de Construção como sua entrada.