24 de março de 2025

Lançada a versão 2.7.2 do DevSecOps Application Lifecycle Management

A versão 2.7.2 do DevSecOps Application Lifecycle Management está disponível no catálogo IBM Cloud.

Esta versão amplia o suporte lançado anteriormente para as integrações de ferramentas de repositório, adicionando suporte para que a ferramenta de repositório de aplicativos de amostra seja configurada de forma independente em uma configuração de air gapped.

Como antes, as seguintes variáveis são usadas para configurar uma configuração de abertura de ar. repo_blind_connection, repo_git_id, repo_git_provider, repo_root_url, repo_title

Observação: repo_blind_connection agora é um bool, em vez de um tipo de cadeia de caracteres anteriormente.

Há suporte para três tipos de configurações:

1. Totalmente vedado com ar. Todos os repositórios são configurados com uma conexão cega. Para configurar todos os repositórios padrão com suporte a air gap, as seguintes variáveis devem ser definidas. Defina compliance_pipeline_repo_use_group_settings como true, repo_apply_settings_to_compliance_repos como true e create_git_triggers como false. Consulte as descrições das variáveis para obter mais detalhes.

2. Totalmente vedado com ar, com exceção do repositório de tubulações de conformidade. Defina compliance_pipeline_repo_use_group_settings como false, repo_apply_settings_to_compliance_repos como true e create_git_triggers como false.

3. Parcialmente aberto. Somente os aplicativos de amostra, os repositórios de configuração e os repositórios de implantação têm air gap. Defina compliance_pipeline_repo_use_group_settings como false, repo_apply_settings_to_compliance_repos como false e create_git_triggers como false.

Chave de API de serviço e criação de chave de API

O ibmcloud-api-key e o cos-api-key agora podem ser configurados de diferentes maneiras. Para o ibmcloud-api-key, a configuração de create_ibmcloud_api_key para true por padrão cria uma chave de API de serviço com as permissões relevantes para executar os pipelines. Como efeito colateral, as integrações da ferramenta do repositório devem ser configuradas usando um token de acesso pessoal Git. Consulte repo_git_token_secret_name para obter mais detalhes. Como alternativa, a configuração de force_create_standard_api_key para true criará uma apikey padrão e o acesso será limitado ao grupo de acesso que foi atribuído ao usuário.

Da mesma forma, definir create_cos_api_key como true e definir um nome para a chave cos-api usando cos_api_key_secret_name criará uma chave de API de serviço com as permissões relevantes para que o pipeline em execução interaja com o balde de cos configurado. Além disso, o cos-api-key exige que o cos_instance_crn e o cos_bucket_name sejam definidos para aplicar corretamente as políticas de acesso à chave da API do serviço COS.

Por fim, as chaves de API ibmcloud-api-key e cos-api-key podem ser especificadas usando pipeline_ibmcloud_api_key_secret_value e cos_api_key_secret_value, respectivamente. Consulte as descrições das variáveis para obter mais detalhes.

Acesso ao suporte de grupo

Um grupo de acesso pode ser criado definindo create_access_group como true. O nome do grupo de acesso pode ser definido usando toolchain_access_group_name. Os usuários podem ser atribuídos a esse grupo de acesso, concedendo as permissões relevantes para as operações da cadeia de ferramentas.

Observação: create_code_engine_access_policy ou create_kubernetes_access_policy pode ser definido como true para atender às políticas de um tipo de implantação Kubernetes ou Code Engine.

Referências secretas

Por padrão, as referências secretas usadas pelos pipelines e integrações de ferramentas usam o formato legado e são identificáveis por uma cor roxa. A configuração de use_legacy_ref para false usará o novo formato de referência secreta identificável por uma cor azul-petróleo. As versões futuras usarão o novo formato por padrão.

Para obter mais informações, consulte Variáveis.

9 de dezembro de 2024

Lançada a versão 2.5.0 do DevSecOps Application Lifecycle Management

A versão 2.5.0 do DevSecOps Application Lifecycle Management está disponível no catálogo IBM Cloud.

Atualização para a versão 2.5.0

Atualização a partir da versão 2.4.3

Ao fazer upgrade da versão 2.4.3, defina a variável compliance_pipeline_repo_name como compliance-pipelines para evitar a substituição forçada da integração da ferramenta compliance-pipelines.

Não defina essa variável se estiver fazendo upgrade de 2.0.3 para 2.5.0.

Atualização a partir da versão 2.0.3

Durante o processo de atualização, um recurso não utilizado do Terraform do tipo random_string é destruído.

Problemas corrigidos

A propriedade de pipeline slack-notifications agora é calculada corretamente ao ativar a integração da ferramenta Slack.

Novos recursos

O suporte para a integração de uma ferramenta de trabalhador privado já está disponível. As seguintes variáveis são usadas para configurar a integração da ferramenta de trabalhador privado:

• privateworker_name
• privateworker_credentials_secret_name
• privateworker_secret_value
• create_privateworker_secret
• enable_privateworker

Informações Adicionais

Os módulos individuais CI, CD e CC usados pelo ALM introduzem uma nova variável que especifica o nome do repositório de tubulações de conformidade. Embora essa variável não seja usada na configuração padrão, ela pode causar uma substituição forçada da integração do repositório. Observe que isso não afeta o repositório em si, apenas a integração da ferramenta.

Configuração do trabalhador privado

Para adicionar um trabalhador privado ao seu conjunto de cadeias de ferramentas:

1. Defina a variável enable_privateworker como true para adicionar a integração da ferramenta de trabalho às suas cadeias de ferramentas.
2. Defina a variável create_privateworker_secret como true para criar um segredo em sua instância Secrets Manager.
3. Forneça a chave da API do serviço para seu trabalhador privado na variável privateworker_secret_value.
4. Especifique o nome secreto na variável privateworker_credentials_secret_name onde a chave da API do serviço será armazenada.

É necessário ter uma chave de API de serviços de trabalhadores privados.

Para obter mais informações, consulte Variáveis.

6 de novembro de 2024

Lançada a versão 2.4.3 do DevSecOps Application Lifecycle Management

A versão 2.4.3 do DevSecOps Application Lifecycle Management está disponível no catálogo IBM Cloud.

Os módulos individuais de CI, CD e CC aproveitados pelo ALM introduzem uma nova variável que especifica o nome do repositório compliance-pipelines. A variável não é usada na configuração padrão, mas causa uma substituição forçada da integração do repositório. Não há exclusão do repositório em si, apenas a integração da ferramenta.

Um recurso não utilizado do Terraform do tipo random_string havia sido criado anteriormente usando as configurações padrão. Você verá isso sendo destruído na atualização.

Configuração dos repositórios de conformidade usando uma conexão cega para dar suporte a ambientes com espaço livre de ar.

As seguintes variáveis de nível de grupo aplicam as configurações aos repositórios de conformidade padrão: repo_blind_connection, repo_git_id, repo_git_provider, repo_root_url, repo_title

Defina repo_blind_connection como true para habilitar uma conexão cega, defina repo_git_id como o ID do Git para os repositórios de conformidade e repo_git_provider como o tipo de provedor Git, por exemplo, GitHub ou GitLab. repo_root_url deve ser definido como o URL raiz do servidor, por exemplo, https://git.example.com. e repo_title com um título para o servidor. Os repositórios também podem ser configurados individualmente com versões específicas do repositório das variáveis acima.

Suporte para provisionar segredos na instância do Configured Secrets Manager, especificamente um token git e as chaves de assinatura. As variáveis necessárias são as seguintes:

create_git_token repo_git_token_secret_name repo_git_token_secret_value create_signing_key rotate_signing_key ci_signing_key_secret_name cd_code_signing_cert_secret_name

Definir create_git_token como true, repo_git_token_secret_name como my-git-token e especificar um token de acesso pessoal Git em repo_git_token_secret_value resultará em um segredo chamado my-git-token com o valor especificado em repo_git_token_secret_value sendo criado no Secrets Manager. É importante observar que a configuração de repo_git_token_secret_value altera o comportamento da autenticação usada pelas ferramentas do repositório. Os repositórios agora esperam usar um token de acesso e um nome de usuário/proprietário para seus repositórios. Esse nome de proprietário precisa ser definido em ' repo_group. Esse comportamento pode ser substituído usando a variável de tipo de autenticação que está associada a cada repositório específico e revertida para o acesso oauth. Essas variáveis terminam com " _repo_auth_type, por exemplo, " issues_repo_auth_type

A configuração de create_signing_key para true gera uma chave de assinatura e o certificado de validação de assinatura correspondente. Os nomes desses segredos são especificados em " ci_signing_key_secret_name e " cd_code_signing_cert_secret_name.

Os segredos de assinatura gerados podem ser girados definindo " rotate_signing_key como verdadeiro. Essa chave girará tanto a chave de assinatura quanto o certificado de validação de assinatura. É importante fazer uma cópia do certificado de validação caso haja implantações pendentes que tenham sido assinadas com a chave de assinatura anterior.

Essa versão também oferece suporte ao uso do GitLab como fonte para os repositórios e um meio simplificado de alterar o provedor Git. Consulte o repo_git_provider. Defina essa variável como ' GitLab para configurar todas as ferramentas de repositório de conformidade criadas pelo DA para usar GitLab.

Para usar GitLab como provedor, é necessário fornecer um token de acesso para o GitLab e o nome do usuário/proprietário. O nome do token de acesso pode ser definido em " repo_git_token_secret_name, que se aplica a todos os repositórios de conformidade, e o nome do proprietário do repositório pode ser definido usando " repo_group.

Elas podem ser configuradas individualmente usando as variáveis que terminam com " _repo_git_token_secret_name e " _group. Por exemplo, " issues_repo_git_token_secret_name e " issues_group

Para obter mais informações, consulte Variáveis.

26 de setembro de 2024

Lançada a versão 2.0.3 do DevSecOps Application Lifecycle Management

A versão 2.0.3 do DevSecOps Application Lifecycle Management está disponível no catálogo IBM Cloud.

Configuração simplificada do pipeline: Todas as propriedades padrão e personalizadas do pipeline agora são definidas usando uma única variável JSON para cada tipo de pipeline (CI, CD e CC).

Alterações e aprimoramentos

• Configuração e gerenciamento simplificados do pipeline
• Usabilidade aprimorada com nomes de variáveis JSON que correspondem a nomes de propriedades do pipeline
• Redução da complexidade com todas as propriedades do pipeline em um único local

Esta atualização é uma mudança radical. Atualize com cautela. Para garantir uma transição tranquila, siga estas etapas:

1. Registre as propriedades e os valores atuais do pipeline para as cadeias de ferramentas CI, CD e CC.
2. Atualize as variáveis JSON usando os seguintes modelos:
   • Para a versão Kubernetes das cadeias de ferramentas, use CI JSON, CD JSON e CC JSON.
   • Como alternativa para a variante Code Engine, use CI JSON, CD JSON e CC JSON.
3. Adicione quaisquer propriedades personalizadas especificadas anteriormente às variáveis JSON atualizadas.

O tipo de variável mais comum é a propriedade text, que assume o formato:

  {
    "name": "opt-in-dynamic-scan",
    "type": "text",
    "value": "1"
  }

Os segredos são definidos da seguinte forma:

  {
    "name": "git-token",
    "type": "secure",
    "value": "my-github-token"
  }

Você pode definir o valor como um tipo seguro de uma das três maneiras a seguir:

Nome do segredo: use o nome do segredo como ele aparece no provedor de segredos. A referência completa ao segredo é calculada automaticamente com base no Secrets Manager e no grupo de segredos especificado durante a criação do DA. CRN: defina um nome de recurso de nuvem (CRN) para um segredo. Isso requer uma integração Secrets Manager configurada no modo CRN. Referência completa do segredo: Defina a referência completa do segredo, por exemplo, {vault::sm-compliance-secrets.Default.my-github-token}. Essa abordagem permite que você especifique diferentes grupos secretos.

Há diversas variáveis existentes que agora operam em conjunto com as pré-operações JSON. Esses são os seguintes: app_repo_branch, cluster_name, cluster_namespace, cluster_region, code_engine_project, code_engine_region, code_engine_resource_group, code_signing_cert_secret_name, cos_api_key_secret_name, cos_bucket_name, cos_endpoint, dev_region, dev_resource_group, environment_tag, pipeline_doi_api_key_secret_name , doi_toolchain_id, doi_toolchain_id_pipeline_property, pipeline_ibmcloud_api_key_secret_name, region, registry_namespace, registry_region, signing_key_secret_name, pipeline_config_repo_branch

O objetivo dessas variáveis é permitir uma maneira alternativa de especificar o valor de uma propriedade do pipeline. Elas são variáveis auxiliares. Veja, por exemplo, as variáveis que terminam com ' region. Eles serão definidos automaticamente com a região correspondente à variável " toolchain_region. O " cluster_region pode ser definido explicitamente ou herdará o valor definido em " toolchain_region. Dessa forma, a propriedade de pipeline equivalente no JSON pode ser deixada em branco, mas ainda precisa ser especificada para que a propriedade de pipeline seja criada. A definição do valor no JSON tem a precedência mais alta e, quando definida, substituirá quaisquer valores definidos nas variáveis acima.

  {
    "name": "cluster-region",
    "type": "text",
    "value": ""
  }

Outro caso especial é o " doi_toolchain_id. A menos que você saiba de antemão que gostaria que a integração DevOpInsights apontasse para uma cadeia de ferramentas específica que já existe, deixe essa entrada vazia e o DA fornecerá automaticamente a ID para você.

É possível que a atualização falhe e isso provavelmente se deve ao fato de adicionar propriedades de pipeline aos pipelines manualmente por meio da interface do usuário em vez de por meio de projetos. O erro provável nesse caso, que é visto nos registros, será ' duplicate property error. Para resolver esse problema, você terá de remover a propriedade problemática na interface do usuário e, em seguida, executar novamente a etapa de implantação de projetos do DA. Se a propriedade não for facilmente identificável, exclua todas as propriedades do pipeline, exceto as propriedades de integração da ferramenta do repositório.

Se a propriedade não aparecer no JSON, ela não aparecerá nas propriedades do pipeline após a implantação. Desde que a propriedade tenha um valor vazio definido, você poderá usar as variáveis listadas acima, se necessário.

A versão 2.0.3 tem duas outras alterações significativas:

• Há uma redução significativa no número de variáveis disponíveis para configuração. Aproximadamente uma redução de 60%. Isso se deve a uma combinação do uso dos JSONs de propriedade do pipeline e da adição de mais variáveis de nível de grupo e da ocultação de suas variáveis relacionadas. Por exemplo, ' cos_bucket_name define o nome do balde de cos em todas as três cadeias de ferramentas e as variáveis relacionadas de ' ci_cos_bucket_name, ' cd_cos_bucket_name e ' cc_cos_bucket_name agora estão ausentes.

• Propriedades bloqueadas: Esse é um novo recurso criado para limitar o controle dos usuários que só têm permissão para executar os pipelines. Quando a propriedade estiver bloqueada, ela não estará disponível para edição durante a execução de um pipeline. Várias propriedades agora estão bloqueadas por padrão. Para desbloquear essas propriedades, identifique a propriedade necessária no JSON de propriedades e adicione a seguinte linha:

{
  "name": "doi-ibmcloud-api-key",
  "type": "secure",
  "value": "ibmcloud-api-key",
  "locked": "false"
}

Pequenas alterações

• O nome padrão original do ci_signing_key_secret_name foi atualizado para signing-key.
• A correção automática de CRA agora está ativada por padrão.
• A configuração para trazer seu próprio aplicativo de amostra foi simplificada e, nos casos em que o aplicativo de amostra reside no Git ou no Git Repos hospedado IBM e no rastreamento de problemas, ele calculará automaticamente a configuração do provedor para você. Eles ainda podem ser definidos explicitamente. As variáveis require agora são apenas app_repo_existing_url, app_repo_branch e app_repo_git_token_secret_name se um token Git for necessário para acessar o repositório.

21 de junho de 2024

Lançada a versão 1.8.0 do DevSecOps Application Lifecycle Management

A versão 1.8.0 do DevSecOps Application Lifecycle Management está disponível no IBM Cloud catalog.

Essa versão apresenta funcionalidades adicionais dos pipelines DevSecOps, incluindo opções para modificar o comportamento das varreduras de CRA e Event Notifications. ci_cra_bom_generate, ci_cra_deploy_analysis, ci_cra_vulnerability_scan, pr_cra_bom_generate, pr_cra_deploy_analysis, pr_cra_vulnerability_scan, ci_enable_pipeline_notifications, ci_event_notifications, ci_pipeline_properties, ci_repository_properties, cd_enable_pipeline_notifications, cd_event_notifications, cd_pipeline_properties, cc_cra_bom_generate, cc_cra_deploy_analysis, cc_cra_vulnerability_scan, cc_enable_pipeline_notifications, cc_event_notifications, cc_pipeline_properties

Para obter mais informações, consulte Variáveis

Esta versão apresenta um novo recurso de personalização. As variáveis ci_pipeline_properties, cd_pipeline_properties e cc_pipeline_properties permitem que o usuário adicione propriedades personalizadas aos pipelines CI, CD e CC usando as variáveis prefixadas relevantes.

O exemplo a seguir usa o ci_pipeline_properties que tem como alvo a cadeia de ferramentas de CI. Observe as linhas pipeline_id no JSON que têm valores ci e pr e denotam os pipelines CI e PR. Ao usar as variáveis cd_pipeline_properties e cc_pipeline_properties, usar cd e cc como valores direcionará os respectivos pipelines para adicionar as novas variáveis. O exemplo destaca a adição de propriedades personalizadas de texto, segredo e enum de pipeline. Observe que, para a propriedade de tipo seguro, basta especificar apenas o nome do segredo na instância padrão Secrets Manager. Alternativamente, a referência secreta completa pode ser fornecida, por exemplo, {vault::sm-compliance-secrets.custom-secret-group.secret-name}

[
  {
    "pipeline_id": "ci",
    "properties": [
      {
        "name": "custom-param1",
        "type": "text",
        "value": "example1"
      },
      {
        "name": "custom-param2",
        "type": "secure",
        "value": "grit-token"
      },
      {
        "name": "custom-param3",
        "type": "single_select",
        "value": "0",
        "enum": "[0,1,2]"
      }
    ]
  },
  {
    "pipeline_id": "pr",
    "properties": [
      {
        "name": "custom-param1",
        "type": "text",
        "value": "example1"
      }
    ]
  }
]

Além disso, a cadeia de ferramentas de CI tem uma variável chamada ci_repository_properties que permite ao usuário adicionar repositórios novos ou existentes à cadeia de ferramentas de CI. O comportamento padrão é que os repositórios listados tratarão os repositórios como existentes em vez de tentar clonar esses repositórios.

O exemplo a seguir destaca como adicionar repositórios adicionais à cadeia de ferramentas de CI. Observe que as entradas de nível superior no JSON são herdadas pelos elementos filhos e podem ser substituídas por entradas nos elementos filhos com o mesmo nome de chave. Dois repositórios estão listados no exemplo. O primeiro repositório é o caso mais básico. Ele contém um repository_url e um default_branch. O default_branch substitui o valor master por main. O padrão mode é link. Como o repositório está no GitHub, ele requer um token Git. Isso é especificado no nível superior do JSON. Esse valor precisa estar no provedor de segredos. Especificar o repositório como tal resultará na criação automática de acionadores para o repositório, ou seja, um acionador Git, um acionador manual e um acionador PR.

O segundo repositório listado está no modo clone e tentará clonar o repositório no GRIT. Se um name não for fornecido para o repositório, ele usará o mesmo nome do repositório que está sendo clonado.

Esse segundo exemplo também mostra a criação de acionadores personalizados. Deve-se observar que a adição de acionadores personalizados impedirá a criação de acionadores automáticos.

[
  {
    "pipeline_id": "ci",
    "repository_owner": "owner_name",
    "default_branch": "master",
    "repositories": [
      {
        "repository_url": "https://github.com/open-toolchain/secure-kube-toolchain",
        "default_branch": "main",
         "git_token_secret_ref": "github-token",
      },
      {
        "repository_url": "https://github.com/open-toolchain/hello-containers",
        "mode": "clone",
        "name": "clone-of-hello-containers",
        "triggers": [
          {
            "type": "manual",
            "name": "Manual Trigger1",
            "properties": [
              {
                "type": "text",
                "name": "param1",
                "value": "example1"
              }
            ]
          }
        ]
      }
    ]
  }
]

15 de maio de 2024

Lançada a versão 1.2.1 do DevSecOps Application Lifecycle Management

A versão 1.2.1 do DevSecOps Application Lifecycle Management está disponível no IBM Cloud catalog.

• Opções adicionais para configurar o nome dos projetos Code Engine na variante Code Engine, code_engine_project, code_engine_project_prefix, ci_code_engine_project_prefix e cd_code_engine_project_prefix.

Para obter mais informações, consulte Variáveis

22 de março de 2024.

Lançada a versão 1.1.0 do DevSecOps Application Lifecycle Management

A versão 1.1.0 do DevSecOps Application Lifecycle Management está disponível no IBM Cloud catalog.

• Suporte do CRN incluído para o Secrets Manager Configure sm_instance_crn com o CRN da instância do Secrets Manager. No mínimo dois segredos do CRN, precisam ser fornecidos Configure pipeline_ibmcloud_api_key_secret_crn com o CRN para a chave de API que executa os pipelines e configure ci_signing_key_secret_crn com o CRN para a chave de assinatura.

• Suporte incluído para as varreduras GoSec Configure opt_in_gosec como 1 para ativar varreduras GoSec. Consulte DevsecOps Docs

• Suporte para usar uma tag Git para selecionar uma versão das definições de Pipelines de conformidade na seção de definições de pipeline. A recomendação é usar as configurações atuais, que usam automaticamente a versão mais recente do Compliance Pipelines. Para especificar uma tag, use pipeline_git_tag

• Suporte para ativar validação de artefato. Consulte DevsecOps Docs O nome secreto do certificado de assinatura esperado é signing-certificate. Se isso já estiver configurado no provedor de segredos sob um nome de segredo diferente, ele poderá ser atualizado configurando cd_code_signing_cert_secret_name para corresponder ao nome da entrada de segredo existente...

Se você estiver fazendo upgrade da versão 1.0.7 para 1.1.0, selecione a variante que corresponde à sua configuração atual Se print-code-signing-certificate estiver configurado nas propriedades de pipeline de IC, exclua a entrada antes de continuar Da mesma forma para code-signing-cert no pipeline CD. Isso causará uma falha de atualização se presente. Se ocorrer uma falha, certifique-se de que essas propriedades de pipeline tenham sido removidas e, em seguida, tente novamente

11 de dezembro de 2023. "

Lançada a versão 1.0.7 do DevSecOps Application Lifecycle Management

A versão 1.0.7 do DevSecOps Application Lifecycle Management está disponível no IBM Cloud catalog.

• Agora é possível implementar um aplicativo de amostra com IBM Cloud Code Engine.

• Suporte incluído na cadeia de ferramentas CC para correção automática de vulnerabilidades usando CRA para tipos de aplicativos suportados.

• DevSecOps O Application Lifecycle Management agora usa a versão open-v10 dos pipelines de conformidade. Fazer upgrade de 1.0.6 para 1.0.7 nos projetos IBM Cloud também atualizará a versão para open-v10. É possível mudar explicitamente a versão usando a variável compliance_pipeline_branch

• Suporte incluído para o SonarQube

• Um acionador de validação foi incluído no pipeline do CD para validar as promoções do Git

Se estiver fazendo upgrade da versão 1.0.6 para 1.0.7, selecione a opção Deploy to Kubernetes de 1.0.7

02 de outubro de 2023.

Lançada a versão 1.0.6 do DevSecOps Application Lifecycle Management

A versão 1.0.6 do DevSecOps Application Lifecycle Management está disponível no IBM Cloud catalog.

• A inclusão do IBM do novo suporte de perfil do Security and Compliance Center.

• O suporte do IBM Cloud Event Notifications para diversos grupos de segredos ao usar o Secrets Manager.

• Para obter mais informações, consulte Variáveis obrigatórias e opcionais. Novas variáveis SCC são prefixadas com scc_ e variáveis de grupo de segredos são sufixadas com _secret_group.

08 de setembro de 2023.

Lançada a versão 1.0.5 do DevSecOps Application Lifecycle Management

A versão 1.0.5 do DevSecOps Application Lifecycle Management está disponível no IBM Cloud catalog.

• As definições do IBM Managed Compliance Pipelines podem ser configuradas em todos os pipelines usando o compliance_pipeline_branch ou em uma base de pipeline usando ci_compliance_pipeline_branch, ci_compliance_pipeline_pr_branch, cd_compliance_pipeline_branch ou cc_compliance_pipeline_branch. O valor padrão é open-v9.

• A ferramenta IBM Cloud Event Notifications pode ser incluída nas cadeias de ferramentas de IC, CD e CC usando event_notifications_crn com o CRN do serviço Event Notifications existente ou em uma cadeia de ferramentas específica usando ci_event_notifications_crn, cd_event_notifications_crn ou cc_event_notifications_crn.

• Alguns nomes de variáveis foram atualizados para a consistência. evidence_repo_url é agora evidence_repo_existing_url. issues_repo_url é agora issues_repo_existing_url. inventory_repo_url é agora inventory_repo_existingurl. Nomes de variáveis antigos e novos funcionam, mas o código deve ser atualizado para usar os novos nomes de variáveis.

• Os acionadores agora podem ser nomeados, ativados e desativados Por exemplo, ci_trigger_manual_name e ci_trigger_manual_enable.. Para obter mais informações, consulte Variáveis obrigatórias e opcionais.

A versão 1.0.5 aborda um problema em potencial no qual a varredura padrão do Sonarqube falha ao ser executada e, em vez disso, tenta se conectar a um servidor customizado. O problema pode ser corrigido na liberação 1.0.4 excluindo o parâmetro de texto sonarqube das propriedades de pipeline de CI e CC. Isso foi configurado como {} anteriormente

26 de maio de 2023.

Lançada a versão 1.0.4 do DevSecOps Application Lifecycle Management

A nova versão suporta uma configuração simplificada. Ele introduz várias variáveis adicionais que agem como variáveis de grupo. Para obter mais informações, consulte Variáveis obrigatórias e opcionais. Por exemplo, a variável toolchain_region agora configura a região para as cadeias de ferramentas CI, CD, CC, bem como a região de cluster e a região de registro de contêiner.

20 de Abril de 2023

Apresentando o DevSecOps Application Lifecycle Management

O DevSecOps Application Lifecycle Management é lançado. É possível usar a arquitetura implementável para criar um conjunto de cadeias de ferramentas e pipelines do DevOps A arquitetura implementávelCloud automation for deploying a common architectural pattern that combines one or more cloud resources that is designed for easy deployment, scalability, and modularity. é baseada na arquitetura de referência do IBM Cloud for Financial Services.