Configurando vários aplicativos em uma cadeia de ferramentas de integração contínua

Ao executar ofertas de serviço por meio da Integração Contínua (CI), considere consolidar todos os microsserviços ou componentes de suas ofertas em uma única cadeia de ferramentas comum, em vez de gerenciar várias cadeias de ferramentas para cada repositório.

Para configurar o Pipeline de IC e o pipeline de solicitação pull(PR) para trabalhar para vários repositórios de aplicativos é simples. Use as seguintes etapas e mudanças para permitir o uso de vários aplicativos.

Customização da cadeia de ferramentas

Customize sua cadeia de ferramentas incluindo sua cadeia de ferramentas em vários apps e aumente sua funcionalidade Estas são as etapas:

  1. Adicione uma GitHub integração de ferramenta para cada aplicativo que você deseja construir nos pipelines da cadeia de ferramentas.
  2. Inclua mais integrações do GitHub para qualquer problemaextra, inventário e evidência repositórios que possam ser configurados para determinados aplicativos.
  • Consulte as páginas da documentação e as orientações de melhores práticas para saber se esses repositórios de aplicativos adicionais serão necessários.

  • Um subsistema é um grupo de serviços relacionados que são dependentes entre si e são desenvolvidos e implantados em conjunto.

    • Os serviços dentro de um único subsistema devem compartilhar um repositório de inventário e um armário de evidências comuns. Cada subsistema deve manter uma relação 1:1 entre seu repositório de inventário e seu armário de evidências. A pesquisa de evidências em vários armários não é suportada, pois amplia o espaço de pesquisa e aumenta o risco de conflito de dados.
    • Você também pode agrupar vários subsistemas para usar o mesmo inventário e armário compartilhados.
    • Exemplo: Agrupe serviços relacionados (como auth e user-profile) em um único subsistema. Este modelo oferece suporte ao gerenciamento escalável de microsserviços em Continuous Delivery ambientes.
  • Os repositórios de aplicativos também podem servir como seus próprios repositórios de problemas. Isso é aplicável somente quando a opção de problemas do GitHub está ativada na integração de ferramenta..

  • O repositório de inventário deve ser suficiente como um único repositório consolidado para registrar seus registros de compilação, pois os registros já estão divididos pelo app-name, desde que esse parâmetro seja diferente, nada será perdido ou confundido. No entanto, você pode consultar a documentação do inventário para obter ideias sobre como lidar com este repositório, pois sua principal função é ajudar a dar suporte às implantações no pipeline de implantação contínua.

  1. Configure um IBM Cloud® Object Storage bucket.

    O IBM Cloud Object Storage é o método preferencial de armazenamento de evidências para os artefatos de evidências do pipeline e é necessário para a conformidade de auditoria. Use o mesmo depósito do Object Storage para cada aplicativo que você traz na cadeia de ferramentas de IC. Além disso, reutilize o mesmo depósito Object Storage quando estiver integrando sua cadeia de ferramentas de IC com a cadeia de ferramentas de CD ou CC.

  2. Opcional: integrações adicionais do HashiCorp Vault.

    Como a integração de ferramenta HashiCorp Vault suporta apenas um caminho, talvez seja necessário mais deles, dependendo de como seus segredos do HashiCorp Vault são configurados. Aplicativos diferentes podem precisar de credenciais diferentes ou outras entre si.

Personalização do pipeline de CI e RP

Customize seu pipeline de IC e PR configurando-os usando as etapas a seguir:

  1. Crie um acionador Git para cada aplicativo.

    • Copie os acionadores existentes para salvar alguns tedium quando você criar acionadores.
    • Certifique-se de que cada um dos gatilhos esteja apontando para o repositório e o branch GitHub necessários.
    • Certifique-se de que as seguintes propriedades do gatilho estejam definidas:
      • app-name (texto): os nomes de aplicativos devem ser exclusivos nos diferentes aplicativos. Isso ocorre porque o nome do app é usado no inventário, insights do DevOps e outros como um identificador exclusivo quando colocado e registrado com artefatos.
      • cos-bucket-name (texto): O nome do Object Storage bucket em que as evidências das aplicações são colocadas.
  2. As mudanças de propriedade do ambiente para cada aplicativo

    • Esta é uma lista das possíveis propriedades de ambiente cujos valores precisam ser alterados para cada um dos aplicativos. Isso pode ser feito usando as propriedades de gatilho nos gatilhos do pipeline, que substituem as propriedades ambientais pelos valores escolhidos por você.
      • app-name (texto): Os nomes dos aplicativos sempre precisam ser exclusivos entre os diferentes aplicativos, pois o nome do aplicativo é usado no inventário, DevOps nas informações e assim por diante, como um identificador exclusivo ao colocar e registrar artefatos.
      • cos-bucket-name (texto): O nome do Object Storage bucket em que as evidências das aplicações são colocadas.
      • repository (texto): este parâmetro controla qual repositório de aplicativo será clonado para o pipeline e servirá como destino para os pipelines de integração contínua e de solicitações pull para as diversas tarefas de conformidade e segurança.
      • Opcional: evidence-repo (texto): URL do repositório que serve como armazenamento de evidências para a aplicação.
      • Opcional: incident-repo (texto): URL do repositório que serve como repositório de problemas para o aplicativo.
      • Opcional: inventory-repo (texto): URL do repositório que serve como repositório de inventário para a aplicação.
  3. optional step Configure gatilhos manuais para cada um dos aplicativos.

    • Tecnicamente, você precisa apenas de um gatilho manual, pois suas propriedades podem ser editadas no momento da chamada, mas pode ser útil para as equipes ter gatilhos manuais pré-compostos para economizar algumas etapas na escrita de todas as pequenas diferenças possíveis entre os aplicativos.
  4. optional step Crie gatilhos de temporizador para suas aplicações.

    • É uma boa prática reconstruir e revalidar frequentemente uma aplicação, para que você possa se manter a par de quaisquer questões de conformidade e vulnerabilidade, bem como de quaisquer problemas de compilação.
    • Configure as propriedades do acionador da mesma forma que configurou o acionador manual, pois o acionador temporizado é apenas um acionador manual com temporizador.
    • Escalone suas tarefas cron entre si, caso contrário, você poderá sobrecarregar o cluster de trabalho e suas tarefas poderão sofrer aumento no tempo de compilação ou atrasos entre as etapas.

Para obter informações sobre as outras propriedades que podem ser definidas nos gatilhos do pipeline ou nas propriedades do ambiente, consulte o catálogo de parâmetros do pipeline.