Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
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. Os guardrails são estabelecidos e acordados pelas principais partes interessadas. Os stakeholders podem incluir equipes de segurança, operações e arquitetura em toda a organização.
Usando o autoatendimento com guardrails, as equipes de desenvolvimento mantêm a autonomia para tomar decisões de desenvolvimento de forma independente. 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. Os desenvolvedores podem então se concentrar em fornecer valor comercial o mais rápido possível.
[Dizemos aos desenvolvedores], não se preocupem com como tudo funciona, apenas ativem ou desativem as opções, preencha os campos, insira o que for necessário e, nesse sentido, é basicamente autoatendimento, onde há um arquivo README com entradas e saídas, e eles podem adicionar o que acharem melhor. - Daniel, engenheiro de nuvem, empresa de mídia da Fortune 500
O objetivo de fornecer uma experiência de autoatendimento para seus caminhos padronizados é reduzir o trabalho dos desenvolvedores e, ao mesmo tempo, oferecer visibilidade para equipes de desenvolvimento, operações e gestão. A ideia é que você crie uma experiência para uma determinada tarefa que tenha uma curva de aprendizado mínima, graças, em parte, às suas funcionalidades subjacentes de automação e agregação de dados. Além de atividades como 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.
As plataformas de desenvolvedor internas capacitam os desenvolvedores a funcionar como usuários de vitrines digitais.
As plataformas de desenvolvedor internas fornecem recursos semelhantes às vitrines digitais de negócios para empresas. As lojas digitais são inerentemente projetadas para ajudar seus clientes a se autoatendirem. Eles podem lidar com mais capacidade do que as vitrines tradicionais porque fornecem maneiras de descobrir e satisfazer a demanda por itens 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. Operadores, engenheiros de plataforma e outras funções então configuram 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 um pedido em uma loja virtual. Assim 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.
Usar o padrão "tudo como 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 para habilitar o autoatendimento. A IaC com CD permite que você use Bicep, Terraform, gráficos do Helm e outras ferramentas para criar e destruir recursos de nuvem sob demanda. Como a configuração da infraestrutura de nuvem é gerenciada da mesma forma que o código em um repositório de código-fonte, você pode aplicar todos os benefícios de um repositório git, como segurança e auditoria.
Provisionar infraestrutura e ferramentas comuns não é a única vantagem da abordagem IaC. Você pode adaptar o padrão IaC para outros cenários, incluindo segurança como código e política como código (por meio de ferramentas como o Azure Policy e o Open Policy Agent). Seguindo essa técnica, um arquivo de configuração, normalmente YAML ou JSON, é enviado por push para o repositório, que dispara um fluxo de trabalho 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 em seus próprios cenários para realmente tornar tudo como código (EaC) uma realidade.
Os desenvolvedores podem referenciar cada um desses modelos EaC com um catálogo central que capacita suas experiências de autoatendimento e incentiva as práticas recomendadas por padrão.
Criar modelos para iniciar corretamente e estabelecer governança para manter corretamente
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 iac centralmente protegidos e reutilizáveis como blocos de construção para infraestrutura.
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
Combine IaC, EaC e modelos de aplicativo em uma solução personalizada EaC (tudo como código) que se estende a outras atividades, como criar um repositório de código-fonte, inserir código de exemplo ou fornecer configuração e código de exemplo para ferramentas de observabilidade recomendadas. Esses modelos de IaC, EaC e aplicativos podem ser armazenados ou referenciados de um local central protegido, como um repositório, o catálogo em Ambientes de Implantação do Azure ou o Registro de Contêiner do Azure para cloud-native.
Quando os modelos de início correto são combinados com governança automatizada, verificação e configuração de política, os desenvolvedores mantêm-se no caminho certo desde o primeiro dia.
Modelos simplificam o desenvolvimento com práticas automatizadas e seguras
Use modelos de aplicativo para inicializar seus caminhos pavimentados definidos para várias decisões e ações importantes que os desenvolvedores tomam ao longo de um projeto. Modelos corretos estabelecem práticas de desenvolvimento seguras e controladas e permitem 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 configura um repositório completo com código-fonte padrão que inclui SDKs ou referências às APIs.
Ao fazer com que esses modelos de aplicativo façam referência a outros modelos centralizados (por exemplo, modelos de IaC), cada um desses blocos de construção individuais torna-se modelos de início corretos por conta própria. Esses modelos são fundamentais 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.
Os modelos garantem a governança, a segurança e a otimização de custos
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 varredura de políticas e segurança necessárias para garantir a conformidade ao longo do ciclo de vida do projeto. Como outro exemplo, os modelos podem configurar regras de proteção de ramificações que impedem fusões não autorizadas em ambiente de 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.
Executar campanhas eficazes para criar comunicação bidirecional
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 de alinhamento para criar um diálogo bidirecional com outras equipes de aplicativos. Os desenvolvedores podem aprender a migrar seu aplicativo enquanto a equipe de engenharia da plataforma aprende simultaneamente mais sobre como melhorar a plataforma para eles.
Trace sua própria jornada
Dada a abrangência de experiências que seus recursos de autoatendimento podem abranger, é crucial concentrar seus esforços de investimento e Planejar e priorizar para que sua plataforma de desenvolvedor interno forneça valor incrementalmente. O percurso de cada organização na criação de sua plataforma de desenvolvedor interno é diferente e seguir uma mentalidade de produto ajuda você a direcionar os locais mais críticos que precisam primeiro de experiências de autoatendimento.