O software program de Integração Contínua/Entrega Contínua (CI/CD) – ou seja, soluções que as equipes usam para construir, testar e implantar aplicativos – percorreu um longo caminho na última década. Embora as organizações antes montassem pipelines de CI/CD usando diferentes ferramentas de código aberto, agora elas têm uma infinidade de plataformas corporativas de CI/CD, de ponta a ponta, suportadas por fornecedores, que podem usar. Como essas soluções oferecem tudo o que as equipes precisam para entregar software program, elas são mais simples de implantar e gerenciar.
No entanto, embora haja benefícios claros na adoção de uma plataforma empresarial de CI/CD, migrar para uma pode ser difícil. Isso representa uma série de desafios, como o risco de inatividade do pipeline de CI/CD e desafios de segurança e conformidade.
É por isso que as empresas que migram para soluções mais recentes de CI/CD devem abordar o processo com um plano detalhado e passo a passo. Aqui está uma olhada nos desafios a serem enfrentados, juntamente com dicas sobre como tornar a migração de CI/CD o mais tranquila possível.
Para fundamentar a discussão, vou me concentrar na migração para o GitHub Enterprise, uma plataforma de CI/CD do GitHub, a plataforma de desenvolvimento de software program agora propriedade da Microsoft. GitHub Enterprise é a opção que vejo cada vez mais empresas escolherem em meu trabalho, ajudando empresas a modernizar suas práticas de TI e entrega de software program.
Desafios para a migração do GitHub Enterprise
Como uma plataforma abrangente de CI/CD disponível como uma solução totalmente hospedada, o GitHub Enterprise é relativamente fácil de usar depois de migrado para ele. O desafio, porém, é colocar seu código na plataforma, além de fazer as alterações necessárias no processo para começar a usar a solução no lugar de um conjunto legado de CI/CD.
Em explicit, espere enfrentar desafios que incluem:
- Atrasos na entrega de aplicativos: um processo de migração demorado e demorado se traduz em tempo de inatividade para operações de CI/CD – o que significa que seus desenvolvedores não conseguirão enviar atualizações de aplicativos. Em última análise, isso pode prejudicar os negócios porque os usuários não recebem melhorias de recursos enquanto seus pipelines de CI/CD estão em transição.
- Riscos de desempenho: A falha em escolher a estratégia de implantação correta do GitHub Enterprise e em configurar a solução de maneira ideally suited pode desacelerar o desempenho de CI/CD e reduzir a produtividade do desenvolvedor devido a problemas como recursos de infraestrutura insuficientes para criar e testar aplicativos.
- Requisitos de treinamento: Desenvolvedores de software program qualificados normalmente podem aprender a usar uma nova plataforma de CI/CD com bastante facilidade, mas ainda há um requisito de aprimoramento. É importante não ignorar a necessidade de fornecer aos desenvolvedores tempo para aprender sobre o GitHub Enterprise (ou qualquer solução para a qual você esteja migrando).
- Segurança e conformidade: para mitigar riscos como a injeção de código malicioso em seus aplicativos, é elementary implementar controles de acesso durante o processo de migração que evitem que usuários não autorizados acessem a nova plataforma de CI/CD.
Melhores práticas para uma migração tranquila do GitHub Enterprise
A boa notícia é que, com a abordagem certa, a migração para o GitHub Enterprise ou uma plataforma de CI/CD semelhante não precisa ser propensa a riscos. As práticas recomendadas a seguir podem ajudar a agilizar o processo.
1. Escolha a opção de hospedagem certa
Como muitas plataformas de CI/CD, GitHub Enterprise está disponível em duas formas básicas: uma opção totalmente gerenciada e baseada em nuvem e uma versão que os usuários podem instalar e gerenciar usando sua própria infraestrutura.
Em geral, a solução totalmente gerenciada tende a ser a melhor escolha porque reduz significativamente o esforço de configuração e manutenção por parte dos usuários. No entanto, a opção auto-hospedada pode ser melhor para organizações que precisam de maior controle sobre seu ambiente de CI/CD. Isso tende a ser especialmente verdadeiro para empresas em setores verticais como finanças e seguros, onde as exigências de segurança e conformidade podem ser mais fáceis de cumprir quando a organização executa software program de CI/CD em sua própria infraestrutura (e, portanto, tem maior controle sobre como os dados confidenciais são gerenciados e protegido).
2. Políticas de acesso granular configuradas
Como a maioria dos pacotes modernos de CI/CD, GitHub Enterprise fornece recursos de controle de acesso que as empresas podem usar para determinar quem pode fazer o quê nas ferramentas de CI/CD. Por exemplo, você pode conceder a alguns desenvolvedores acesso somente leitura ao código-fonte, enquanto permite que outros o modifiquem. GitHub Enterprise também oferece suporte a configurações de acesso baseadas em ambiente, o que significa que você pode configurar diferentes níveis de acesso para os mesmos usuários em ambientes de desenvolvimento/teste e produção.
Como prática recomendada, aproveite essas opções granulares de controle de acesso atribuindo diferentes direitos de acesso a cada equipe que usa sua plataforma de CI/CD. Por exemplo, você pode ter uma equipe administrativa cujos privilégios se estendem à alteração da configuração do GitHub Enterprise, enquanto outra equipe que apenas usa a plataforma tem um nível de acesso menor.
3. Use OpenID Join para integração com ambientes em nuvem
GitHub Enterprise oferece uma opção de gerenciamento de identidade que aproveita o OpenID Join (OIDC) para integração com ambientes de nuvem de terceiros.
Ao aproveitar esse recurso, você pode executar fluxos de trabalho automaticamente (como construções de aplicativos) na infraestrutura de nuvem pública sem precisar armazenar credenciais de acesso à nuvem como segredos de longa duração do GitHub, o que representa um risco de segurança substancial. Além disso, essa abordagem cria automaticamente um log de fluxos de trabalho e execuções de ações do GitHub, que você pode usar para fins de auditoria e monitoramento.
4. Aproveite o logon único
Outra maneira de agilizar a migração para o GitHub Enterprise é integrar a plataforma com qualquer provedor de logon único (SSO) (como Microsoft Entra ou Lively Listing) que sua empresa já usa. Idealmente, você também habilitará a autenticação multifator (MFA) por meio de sua solução SSO para adicionar outra camada de segurança.
Essa abordagem elimina a necessidade de gerenciar as credenciais de acesso do GitHub Enterprise separadamente das suas contas existentes. Também reduz a carga colocada sobre a sua equipe de TI durante a migração porque, em vez de ter que “reinventar a roda”, eles podem simplesmente usar uma solução de login que já existe.
5. Documente tarefas comuns
Para facilitar a curva de aprendizado dos desenvolvedores à medida que eles migram para o GitHub Enterprise, documente tarefas comuns, como migrar código de repositórios locais ou outra plataforma de CI/CD para o GitHub Enterprise.
Essa é outra tática que elimina a necessidade de sua equipe reinventar a roda repetidamente; em vez de forçar cada engenheiro a descobrir como migrar por conta própria, todos podem seguir um plano prescrito.
6. Publique padrões de fluxo de trabalho
Indo um passo além, considere também publicar etapas detalhadas sobre como usar os principais recursos do GitHub Enterprise que provavelmente serão importantes para todas as suas equipes. Por exemplo, você pode detalhar como criar solicitações pull ou construir imagens Docker na plataforma, ou como executar implantações de infraestrutura como código (IaC).
Aqui, novamente, essa estratégia reduz a curva de aprendizado e ajuda a colocar sua equipe em operação na nova plataforma o mais rápido possível.
7. Automatize fluxos de trabalho comuns usando GitHub Actions
Indo ainda mais longe, você pode criar fluxos de trabalho totalmente automatizados para tarefas comuns usando GitHub Actions, um recurso que permite acionar operações automatizadas em várias partes do seu pipeline de CI/CD. Por exemplo, você pode acionar automaticamente a construção de um aplicativo após o check-in do código ou iniciar o teste automaticamente após a conclusão da construção.
Fluxos de trabalho altamente complexos que podem variar entre projetos ou equipes não são bons candidatos para esse tipo de automação, mas as rotinas principais podem ser totalmente automatizadas, tornando ainda mais fácil para sua equipe começar a usar a nova plataforma.