Capacitar desenvolvedores por meio de autoatendimento com guardrails

O autoatendimento com guardrails é o princípio de capacitar as equipes de desenvolvimento a tomar suas próprias decisões dentro de um conjunto de parâmetros bem definidos, ou guardrails, que são estabelecidos e acordados pelos principais stakeholders. Os stakeholders podem incluir equipes de segurança, operações e arquitetura em toda a organização.

A ideia por trás do autoatendimento com guardrails é que as equipes de desenvolvimento podem manter o nível desejado de autonomia para tomar decisões de desenvolvimento independentemente, enquanto a automação e a política ajudam os stakeholders a garantir que a segurança, a conformidade, as operações, os padrões e os custos sejam gerenciados corretamente. Habilitar essa automação requer colaboração entre linhas de equipe para que desenvolvedores, operadores e especialistas possam fazer mais, sem sacrificar a governança necessária. Combinado com a descoberta e a reutilização aprimoradas em proteções definidas pela organização, os desenvolvedores podem se concentrar em fornecer valor comercial o mais rápido possível.

[Dizemos aos desenvolvedores], não se preocupe com o funcionamento de tudo, apenas ative ou desative-o, preencha-o, coloque uma cadeia de caracteres no que você precisa fazer e é basicamente autoatendimento a esse respeito onde eles têm um arquivo de leiame e eles têm entradas, saídas e eles podem colocar o que quiserem. - Daniel, Engenheiro de Nuvem, Empresa de Mídia da Fortune 500

O objetivo de fornecer uma experiência de autoatendimento para seus caminhos pavimentados é reduzir a labuta do desenvolvedor e, ao mesmo tempo, fornecer visibilidade às equipes de desenvolvimento, operações e gerenciamento. A ideia é que você crie uma experiência para uma determinada tarefa que tenha uma curva de aprendizado mínima, graças, em parte, aos recursos subjacentes de automação e agregação de dados. Além de atividades como o provisionamento de infraestrutura, essas experiências podem fornecer acesso a recursos críticos para observabilidade, política, gerenciamento de incidentes e muito mais. A ideia se estende à descoberta e ao compartilhamento de APIs internas, SDKs, juntamente com ferramentas e serviços compartilhados. Essas experiências reduzem a sobrecarga para que as equipes de desenvolvimento possam se concentrar em fazer as coisas.

O tempo necessário para começar a usar um projeto ou uma tarefa é outro fator motivador para experiências de autoatendimento. Uma analogia frequentemente usada para uma plataforma de desenvolvedor interna é que ela fornece recursos semelhantes às vitrines digitais entre empresas. As lojas digitais são inerentemente projetadas para ajudar seus clientes a se autoatendirem. Eles podem lidar com mais taxa de transferência do que as frentes de loja tradicionais porque fornecem maneiras de descobrir e atender itens que são interessantes sem precisar falar com ninguém. Usando essa analogia, os desenvolvedores são o cliente e a plataforma de desenvolvedor interna fornece experiências de autoatendimento semelhantes. Assim como um varejista, operadores, engenheiros de plataforma e outras funções, então, configure um catálogo de itens que os desenvolvedores podem solicitar que sejam projetados para acomodar os guardrails organizacionais.

Por exemplo, você pode pensar em um desenvolvedor solicitando acesso a uma nova ferramenta como se estivesse fazendo uma ordem de vitrine digital. Como um pedido, depois que a solicitação é enviada, o desenvolvedor deseja ser capaz de acompanhar o progresso e saber quando ela é concluída. Nos bastidores, a solicitação deve ser roteada automaticamente para o provedor de atendimento correto para atender à necessidade. Você pode pensar em um de seus sistemas de CI/CD (integração e entrega contínua) como um provedor de atendimento, uma ferramenta GitOps ou uma plataforma de aplicativo prescritiva como um segundo e uma ferramenta de automação de fluxo de trabalho para processos manuais como um terço. Em todos os casos, o desenvolvedor pode autoatendir itens de um catálogo bem definido da mesma maneira.

Para saber mais sobre como implementar esses conceitos, consulte Aplicar sistemas de engenharia de software e Criar uma base de autoatendimento para desenvolvedores.

Usar tudo como padrão de código

O uso de IaC (infraestrutura como código) por meio de pipelines de CD (entrega contínua) e ferramentas do GitOps é uma parte importante da habilitação do autoatendimento. Isso pode permitir que você use gráficos Bicep, Terraform, Helm e outras ferramentas para criar e destruir recursos de nuvem sob demanda. Como a configuração da infraestrutura de nuvem é gerenciada como o código em um repositório de código-fonte, você pode aplicar inerentemente todos os benefícios de um repositório git, como segurança e auditoria.

As equipes de engenharia de plataforma podem aproveitar a IaC ao provisionar a infraestrutura e as ferramentas comuns, mas essa não é a única vantagem de uma abordagem de IaC. Você pode adaptar o padrão "como código" para outros cenários, incluindo segurança como código e política como código (por meio de ferramentas como Azure Policy e Agente de Política Aberta). Seguindo essa técnica, um arquivo de configuração, normalmente YAML ou JSON, é enviado por push para o repositório, momento em que um fluxo de trabalho é disparado que processa o arquivo. Esses arquivos podem ser um repositório de aplicativos, como dependabot.yml ou CODEOWNERS, ou podem ser mantidos em um repositório central separado. Você pode até mesmo estender isso para seus próprios cenários para realmente tornar tudo como código (EaC) uma realidade.

Os desenvolvedores podem referenciar cada um desses modelos de EaC com um catálogo central que alimenta suas experiências de autoatendimento e incentiva as práticas recomendadas por padrão.

Saiba mais sobre tudo como padrão de código.

Criar modelos de início correto & estabelecer a governança de permanência correta

Criaremos módulos para nossos [desenvolvedores]... portanto, em vez de ter que escrever ou se preocupar com qualquer um dos back-end em si, tudo o que eles precisam fazer é se preocupar com o código do aplicativo. - Daniel, Engenheiro de Nuvem, Empresa de Mídia da Fortune 500

No desenvolvimento de software, buscamos encapsulamento, modularidade e capacidade de composição ao projetar aplicativos. Você deve aplicar essa mesma linha de pensamento à engenharia de plataforma por meio da modelagem. Por exemplo, você pode criar e usar um conjunto de modelos de IaC reutilizáveis e protegidos centralmente como blocos de construção para infraestrutura.

Eles podem ser combinados em um modelo de aplicativo personalizado que se refere a esses e a outros blocos de construção de tudo como código (EaC) e se estende a outras atividades, como criar um repositório de código-fonte, propagar código de exemplo ou fornecer configuração e código de exemplo para ferramentas de observabilidade recomendadas. Esses modelos de IaC, EaC e aplicativo podem ser armazenados ou referenciados de um local central e seguro, como um repositório, o catálogo em ADE (Ambientes de Implantação do Azure) ou Registro de Contêiner do Azure (ACR) para nativo de nuvem.

Quando os modelos de início à direita são combinados com governança automatizada, verificação e configuração de política, eles podem ajudar os desenvolvedores a permanecerem desde o primeiro dia.

Iniciar modelos à direita

Os modelos de aplicativo podem ser usados para inicializar seus caminhos pavimentados definidos para várias decisões e ações importantes que os desenvolvedores tomam ao longo de um projeto. Esses modelos de início correto devem estabelecer práticas de desenvolvimento seguras e controladas e permitir que os desenvolvedores comecem rapidamente habilitando a automação que fornece acesso às ferramentas necessárias, configura pipelines de CI/CD, provisiona a infraestrutura e a pilha de aplicativos e configurando um repositório completo com código-fonte clichê que inclui SDKs ou referências necessárias a APIs.

Ao fazer com que esses modelos de aplicativo referenciem outros modelos centralizados (por exemplo, modelos de IaC), cada um desses blocos de construção individuais pode se tornar modelos de início corretos para simplificar o uso em aplicativos existentes. Esses modelos são centrais para habilitar experiências de autoatendimento, pois eles não apenas definem saídas, mas também opções disponíveis que os desenvolvedores escolhem.

Manter a governança certa

No entanto, os modelos devem fazer mais do que apenas inicializar um esforço de desenvolvimento. Eles também devem estabelecer o controle e a governança por meio da verificação de política e segurança necessárias para permanecer ao longo do ciclo de vida do projeto. Como outro exemplo, os modelos podem configurar regras de proteção de branch que impedem mesclagens não autorizadas em produção. Como os modelos capturam práticas recomendadas e configurações comuns, eles são uma das principais técnicas para otimizar os custos entre ferramentas, fornecedores e equipes.

Obter campanhas certas

Por fim, à medida que sua confiança em seus caminhos pavimentados aumenta, você pode usar os blocos de construção individuais subjacentes montados em seus modelos de aplicativo para mover aplicativos existentes para um caminho pavimentado. Como seus clientes internos já verão o valor de seus caminhos pavimentados pilotados, você pode executar uma campanha interna get right para criar uma caixa de diálogo bidirecional com outras equipes de aplicativos. Os desenvolvedores podem aprender a migrar seu aplicativo enquanto a equipe de engenharia de plataforma aprende simultaneamente mais sobre como melhorar a plataforma para eles.

Saiba mais sobre como iniciar modelos corretos com a governança correta.

Mapear sua própria jornada

Dada a amplitude de experiências que seus recursos de autoatendimento podem abranger, é um foco importante para seus esforços de investimento e Planejar e priorizar para que sua plataforma de desenvolvedores interna forneça valor incrementalmente. O percurso de cada organização na criação de sua plataforma de desenvolvedor interno será diferente e seguir uma mentalidade de produto ajudará você a direcionar os locais mais críticos que precisam de experiências de autoatendimento primeiro.

Saiba mais sobre como mapear um percurso de engenharia de plataforma.

Melhorar a descoberta, eliminar o desperdício por meio de inventários e acompanhamento de relacionamento