Criar uma base de autoatendimento do desenvolvedor

Depois de ter uma boa compreensão do seu destino para seus sistemas de engenharia, você pode começar a criar experiências de autoatendimento de desenvolvedor mais sofisticadas. Nesta seção, descrevemos uma arquitetura conceitual para criar ou avaliar produtos que criam uma base flexível para criá-los. Nos referimos a esses conceitos, padrões e componentes, coletivamente, como uma base de autoatendimento do desenvolvedor.

Embora talvez você não precise de tudo descrito aqui em sua organização hoje, você deve ter esses conceitos em mente se criar algo personalizado ou avaliar produtos relacionados. Em seu mundo, esse modelo pode ser composto por uma combinação de produtos domésticos, fora da prateleira e de software livre. Produtos ou kits de ferramentas de portal de software livre, como Backstage.io , podem usar termos diferentes para alguns elementos do modelo descritos nesta seção, mas o modelo ainda pode ajudar a orientá-lo.

Goals e considerações

O objetivo principal para seus esforços nessa área deve ser habilitar o autoatendimento com guardrails por meio de execução e provisionamento de tarefas controlados e controlados, juntamente com visibilidade centralizada. As áreas que geralmente são as mais valiosas para se concentrar são aquelas que são tediosas ou são coisas que o desenvolvedor não pode fazer por conta própria devido à complexidade ou permissões. Esta última peça é importante para permitir que você siga o princípio de privilégios mínimos sem forçar os desenvolvedores por meio de um processo manual de service desk.

Embora você possa optar por estender seu pacote de DevOps para atender a essas necessidades, você provavelmente precisará dar suporte a várias plataformas de aplicativos ao longo do tempo, e as ferramentas e processos específicos que dão suporte a elas também precisarão mudar. O principal problema é que seus padrões são um destino móvel. Como um profissional de engenharia de plataforma afirmou:

As dificuldades envolvem padronização... e lidar com 'abandonware'... A padronização geralmente não é alcançada devido a possíveis interrupções de processos automatizados e à tarefa demorada de identificar as alterações necessárias. - Martin, Engenheiro de DevOps, Empresa de Logística Grande

Como esta citação realça, a mudança rápida para um padrão novo ou atualizado normalmente não é viável e abandonar processos existentes cria risco. Sua organização pode já estar usando vários pacotes de DevOps ou combinações diferentes de ferramentas individuais e serviços de desenvolvedor por cenário. Mesmo com uma equipe central e uma solução padrão, à medida que suas necessidades de autoatendimento aumentam, a variabilidade é inevitável. Portanto, você desejará habilitar a experimentação controlada em que as equipes designadas possam experimentar novas tecnologias, estratégias de implantação e assim por diante, seguidas de adoção deliberada e uma distribuição incremental.

Geralmente, as experiências de autoatendimento se enquadram em duas categorias principais:

• Automação
• Agregação de dados

Embora a agregação de dados crie boas experiências de usuário, como disse um profissional de engenharia de plataforma:

A automação é fundamental e será amada por todos. [Dados] a agregação é secundária. – Peter, líder de engenharia de plataforma, empresa multinacional de tecnologia

Por esse motivo, é provável que o percurso de engenharia de plataforma que você mapeou tenha identificado alguns problemas que poderiam ser resolvidos pela automação. Além de reduzir a carga cognitiva e a labuta do desenvolvedor, a automação também pode ajudar a garantir que os aplicativos estejam conectados às melhores ferramentas e serviços para operações, segurança e outras funções para realizar seu trabalho.

No entanto, se você estiver trabalhando com mais de um sistema para impulsionar sua automação, algum nível de agregação de dados será útil para ajudar a acompanhar as solicitações automatizadas e os resultados associados. Muitas vezes, você pode começar vinculando-se a sistemas externos para atender a outras necessidades ou para detalhamento. A agregação e a visibilidade de dados também são importantes para auditar, controlar e reduzir o desperdício (exemplo: ambientes não utilizados).

A automatização de itens como o provisionamento de infraestrutura pode ser feita usando integrações do sistema, mas você também pode disparar e facilitar um processo manual de fluxo de trabalho que parece automatizado para o desenvolvedor. Isso é útil nos estágios iniciais da sua plataforma, para novos produtos que você está trazendo para o ecossistema ou em áreas que você não tem ou não pode automatizar usando um sistema (por exemplo, atribuição de licença de software). Com o design certo, você pode começar com um processo manual facilitado por algo como o Power Automate que você alterna para um fluxo totalmente automatizado ao longo do tempo. Portanto, projete para uma automação desde o início.

Dada uma mentalidade de produto e a ideia de uma TVP (plataforma viável) mais fina ( um MVP para sua plataforma), você deve começar simples reutilizando investimentos existentes, como seus sistemas de engenharia ou um portal interno, criando CLIs, páginas da Web básicas ou até mesmo painéis do Power Pages, do Power BI ou do Microsoft Fabric e expandindo conforme a necessidade surge. Com isso em mente, ter uma API consistente que o UX usa pode ajudá-lo a dar suporte a várias interfaces ao longo do tempo à medida que suas necessidades e preferências mudam.

Visão geral dos conceitos

Considere a ilustração a seguir:

Como mostra a ilustração, os seguintes componentes compõem o núcleo do conceito de uma base de autoatendimento do desenvolvedor:

Componente	Descrição
API da plataforma de desenvolvedor	Esse é seu único ponto de contato para experiências do usuário. É efetivamente o contrato do sistema com outros sistemas.
Grafo da plataforma de desenvolvedor	Um grafo de dados gerenciado e seguro que permite descobrir, associar e usar diferentes tipos de entidades e modelos. Uma entidade é um objeto que habilita a agregação de dados de várias fontes, enquanto os modelos impulsionam entradas de usuário que habilitam a automação.
Orquestrador de plataforma de desenvolvedor	Um recurso que roteia e rastreia solicitações baseadas em modelo para executar ações em um sistema ou por meio de um processo manual. Essas solicitações são roteados para um de um conjunto de provedores de plataforma de desenvolvedor que podem se integrar a qualquer número de sistemas de fluxo de trabalho diferentes ou outros serviços.
Provedores de plataforma de desenvolvedor	Um conjunto de componentes que encapsulam a lógica necessária para integrar com sistemas downstream para dar suporte a operações CRUD em entidades e/ou cumprimento de solicitações de ação baseadas em modelo. Cada provedor pode dar suporte a seu próprio tipo específico de modelos e emitir tipos de entidades exclusivos ou comuns.
Perfil do usuário e metadados de equipe	Uma capacidade de persistir informações sobre um conjunto de indivíduos vinculados a uma equipe conceitual para agrupamento e acesso à API da plataforma de desenvolvedor. O usuário está intimamente associado a uma conta de provedor de identidade (por exemplo, Microsoft Entra ID entrar), mas ela e uma equipe podem se vincular a qualquer número de representações relacionadas do sistema downstream. Uma implementação desse repositório de informações é reutilizar o grafo da plataforma de desenvolvedor. A base de autoatendimento do desenvolvedor pode estabelecer um tipo de entidade comum para um usuário e uma equipe e persistir essas informações no grafo. No entanto, manteremos este repositório separado por uma questão de clareza aqui.

Esses componentes fundamentais permitem que você use e troque diferentes blocos de construção ao longo do tempo. Vamos investigar cada uma delas mais detalhadamente nas seções subsequentes.

Preciso criar tudo isso para começar?

Não. Primeiro, esse é um modelo conceitual para ajudá-lo a pensar no que uma base como essa deve ser capaz de fazer quando for feita. Em segundo lugar, as especificações de implementação são menos importantes aqui, dado que a API da plataforma de desenvolvedor se torna sua interface de chave. Sua implementação inicial pode começar usando interfaces e classes em seu código para as diferentes camadas descritas ou misturadas em outros produtos. Você também pode omitir aspectos porque o desenvolvimento do cliente informa que ele é simplesmente uma prioridade mais baixa. Comece com o que você tem e cresça.

Com isso em mente, vamos nos aprofundar em cada peça.

API da plataforma de desenvolvedor

Você deve definir uma API de plataforma de desenvolvedor para atuar como contrato do sistema. A API é usada por diferentes interfaces do usuário para habilitar o acesso a dados ou o provisionamento de unidade e outras ações.

Essa API também deve atuar como uma importante camada de autenticação e segurança limitando o acesso a APIs subjacentes brutas em outros sistemas a operações e dados controlados mais específicos. A API fornece acesso à própria representação de um perfil de usuário, à função de alto nível de um usuário na plataforma (membro da equipe, administrador etc.) e aos identificadores do sistema do provedor de identidade principal. Para obter mais informações, consulte Usuários e equipes.

Provedores de plataforma de desenvolvedor

Dada a amplitude de uma plataforma de desenvolvedor interna, recomendamos criar ou procurar sistemas que seguem um modelo de provedor extensível para introduzir funcionalidade na API. A ideia é que as principais funcionalidades, como automação e agregação de dados, sejam fornecidas interagindo com componentes conectáveis com interfaces bem definidas. Esse acoplamento flexível ajuda você a conectar o que você precisa incrementalmente e melhora a capacidade de manutenção, pois você pode testar a funcionalidade independente do restante da base.

Também é uma maneira importante de habilitar uma mentalidade de origem interna escalonável para sua plataforma. Normalmente, os esforços internos de fornecimento em torno da engenharia de plataforma não ganham tração devido a desafios com a manutenção contínua. Outras equipes podem estar dispostas a contribuir com a funcionalidade, mas são menos propensas a manter e testar algo dentro do núcleo da sua plataforma. Por outro lado, qualquer equipe centralizada tem capacidade limitada para manter o código contribuido ou até mesmo examinar solicitações de pull. O conceito de um provedor de plataforma de desenvolvedor alivia essa tensão, permitindo que o código escrito independentemente "conecte- se" à funcionalidade principal em sua base de autoatendimento do desenvolvedor. Embora você deva gerenciar cuidadosamente quais provedores você usa, examinar qualquer código do provedor e limitar a área de superfície que um determinado provedor pode acessar em sua plataforma de desenvolvedor, uma abordagem conectável pode ajudá-lo a fazer mais dimensionando o esforço em uma parte mais ampla da organização.

Principais conceitos de provedor de plataforma de desenvolvedor

Entidades

O conceito de uma entidade é algo que um desenvolvedor ou outro sistema em sua plataforma de desenvolvedor interna precisa acompanhar, atualizar, apresentar ou agir. As entidades podem ter relações entre si que, quando juntas, compõem um grafo que fornece informações críticas sobre partes de sua plataforma de desenvolvedor interna. Os provedores de plataforma de desenvolvedor podem, em seguida, gerar entidades para habilitar os principais recursos, incluindo:

• Como exibir recursos/ambientes provisionados externamente ou APIs disponíveis para descoberta e uso
• Expor relações para análise de dependência, análise de impacto, descoberta etc.
• Informações de manutenção/propriedade do surfacing para descoberta e colaboração
• Como exibir mais dados para uso em experiências do usuário

Encapsular essa funcionalidade em uma interface de provedor de plataforma de desenvolvedor bem definida simplifica a integração e o teste, permite a implantação independente e permite que os desenvolvedores fora da equipe de plataforma de desenvolvedor interno primária contribuam e gerenciem provedores. Isso é importante em organizações grandes ou de divisão em que nem todas as ferramentas, serviços ou plataformas são gerenciados centralmente, mas a organização mais ampla ainda deseja compartilhar recursos. Então, mesmo que você não siga esse caminho inicialmente, é algo em que pensar a longo prazo.

Propriedades comuns

Cada entidade deve ter um conjunto de propriedades comuns para permitir que a Fundação as gerencie. Algumas propriedades a serem consideradas incluem:

• Identificador exclusivo
• Nome
• Provedor de origem
• Associações opcionais para:
  • Usuário proprietário
  • Equipe proprietária
  • Outras entidades

As propriedades do usuário e da equipe são importantes por três motivos: RBAC (controle de acesso baseado em função), descoberta e agregação de dados (como resumos de nível de equipe). Criar no RBAC desde o início é fundamental para a segurança e aumentar sua plataforma de desenvolvedor interna ao longo do tempo. Dado que o desenvolvimento é um esporte de equipe, descobrir com quem falar sobre uma entidade rapidamente se tornará crítico para reutilização, suporte e innersourcing.

Entidades comuns e específicas do provedor

Você também deve ser capaz de estabelecer um conjunto de entidades comuns de alto nível normalizadas que vários provedores podem gerar. Por exemplo:

• Ambientes
• Recursos
• Apis
• Repositórios
• Componentes
• Ferramentas

Geralmente, eles devem estar em um alto nível, como você colocaria no contexto do modelo C4 ou no máximo diagramas de componentes de alto nível. Por exemplo, para um ambiente, você não precisa incluir os detalhes da topografia de infraestrutura interna: você só precisa de informações suficientes para listar e associar diferentes ambientes conceituais de vários provedores na mesma experiência do usuário. A entidade pode apontar para níveis mais baixos de detalhes fora do sistema em vez de tentar consumir tudo. Eles fornecem pontos de partida para descoberta que são centrais para habilitar a agregação de dados ao longo do tempo.

Outros serão específicos para um determinado caso de uso ou provedor, portanto, você deve pensar em como você pode acomodar um conjunto crescente de tipos de entidade ao longo do tempo.

Modelos

O conceito de um modelo nesse contexto difere da ideia de entidades, pois elas se destinam a conduzir uma ação. Os cenários de exemplo incluem provisionamento de infraestrutura, criação de um repositório e outros processos de execução prolongada. Esses modelos também devem estar disponíveis por meio de provedores extensíveis de plataforma de desenvolvedor e devem dar suporte às mesmas propriedades comuns que as entidades, incluindo associações de entidade.

No entanto, eles também podem definir as entradas necessárias, sejam elas especificadas pelo sistema ou pelo usuário, que são necessárias para executar a ação. Eles podem variar de qualquer coisa, como nomear o recurso para adições opcionais.

Exemplos de modelos incluem:

• Modelos de IaC (infraestrutura como código)
• Modelos de aplicativo (Iniciar à Direita) ou repositórios de modelo
• Criar modelos de pipeline/fluxo de trabalho
• Pipeline de implantação/modelos de fluxo de trabalho
• Scripts parametrizados
• Fluxos parametrizados do Power Automate (exemplo: um fluxo de nuvem disparado por solicitação HTTP)
• modelos de Email

Assim como as entidades, os modelos podem incluir propriedades específicas do provedor.

Cada modelo pode ter uma representação diferente que seja exclusiva para o provedor. Eles podem variar de modelos do Terraform ou do ARM, até Gráficos do Helm, fluxos de trabalho de GitHub Actions parametrizados ou Azure Pipelines, scripts simples ou formatos personalizados.

Os detalhes reais do modelo subjacente não precisam necessariamente ser armazenados centralmente. Eles podem existir em repositórios, registros ou catálogos diferentes. Por exemplo, você pode usar repositórios de modelos do GitHub para seus modelos de aplicativo, enquanto seus modelos de IaC podem existir em um repositório de catálogo restrito que os desenvolvedores só podem acessar indiretamente por meio de algo como Ambientes de Implantação do Azure. Outros modelos de IaC podem ser armazenados em um Registro de Artefato OCI, como gráficos do Helm. Em outros casos, o modelo pode ser uma referência a um ponto de extremidade HTTP parametrizado. Um provedor de plataforma de desenvolvedor deve fornecer apenas informações suficientes sobre cada tipo de modelo para que ele possa ser referenciado e quaisquer opções expostas para uso em experiências do usuário. Porém, os próprios modelos podem ser hospedados no local mais natural para seus casos de uso.

Engenheiros de plataforma ou especialistas em uma área específica escrevem esses modelos e, em seguida, os compartilham com equipes de desenvolvimento para reutilização. Centralizar o uso desses modelos por meio de um sistema permite o autoatendimento do desenvolvedor e cria proteções que ajudam a impor a conformidade com padrões ou políticas organizacionais. Mais informações sobre isso quando abordarmos o orquestrador da plataforma de desenvolvedor em algum momento.

O grafo da plataforma de desenvolvedor

Você pode pensar em um grafo de plataforma de desenvolvedor como algo que permite associar entidades e modelos de vários provedores a um grafo pesquisável. No entanto, os dados reais das entidades não precisam necessariamente ser persistidos diretamente em um banco de dados específico do grafo. Em vez disso, as interações com provedores podem ser armazenadas em cache junto com os metadados necessários para que tudo se ajuste.

O grafo é poderoso quando usado com entidades comuns que vários provedores podem contribuir. Por exemplo, uma lista de APIs pode vir de um produto como o Centro de API do Azure, mas talvez você também queira alimentar automaticamente em implantações e ambientes de seus sistemas de implantação contínua. Ao longo do tempo, você pode alternar entre diferentes sistemas de implantação ou até mesmo dar suporte a mais de um sistema de implantação. Desde que cada sistema de implantação tenha um provedor de plataforma de desenvolvedor, você ainda deverá ser capaz de fazer a associação.

Cada uma de suas experiências de usuário que se baseiam nesse grafo pode aproveitar uma API comum para impulsionar a descoberta, a pesquisa, a governança e muito mais. Um orquestrador de plataforma de desenvolvedor pode aproveitar esse mesmo grafo para que todas as ações executadas por um provedor de plataforma de desenvolvedor contribuam automaticamente com entidades disponíveis para a mesma API.

Orquestrador de plataforma de desenvolvedor

Um orquestrador de plataforma de desenvolvedor permite que desenvolvedores ou sistemas criem solicitações para executar uma ação usando um modelo. Ele não executa essas ações em si, mas coordena com um mecanismo de tarefas, mecanismo de fluxo de trabalho ou outro orquestrador para fazer isso. É uma das partes críticas que você vai querer ter certeza de que faz parte de sua base de autoatendimento. Ele permite que os desenvolvedores criem solicitações com um modelo ou executem uma ação sem permissão direta. Além disso, ao contrário do conceito de CI ou CD, essas ações não precisam estar relacionadas ao código-fonte do aplicativo.

Conforme descrito em Aplicar sistemas de engenharia de software, você pode usar GitHub Actions, Azure Pipelines ou outro mecanismo de fluxo de trabalho como seu orquestrador. Esse é um lugar razoável para começar, mas talvez você queira ter um pouco de abstração em vigor para permitir que diferentes tipos de modelos usem mecanismos subjacentes diferentes. Isso pode ser útil por alguns motivos:

• Primeiro, você provavelmente desejará ser capaz de escolher diferentes mecanismos de fluxo de trabalho e execução de tarefas ao longo do tempo sem precisar recortar. Ao permitir mais de um mecanismo, você pode migrar ao longo do tempo ou simplesmente o uso do novo mecanismo para novas ações sem afetar as mais antigas.
• Alguns processos que você deseja ajudar a orquestrar podem exigir etapas manuais inicialmente, mesmo que você planeje automatizá-los totalmente mais tarde.
• Outras ações podem ter como alvo funções fora da equipe de desenvolvimento, como contas a pagar ou um administrador de licença. Mecanismos de baixo código, como o Power Automate, geralmente funcionam bem para essas funções.
• Outras ações podem ser tratadas por meio de solicitações HTTP simples em que a rotação de algo tão capaz quanto GitHub Actions ou Azure Pipelines não é necessária ou econômica para dimensionar.

Felizmente, expandir a ideia de um provedor de plataforma de desenvolvedor para abranger as etapas de automação de gatilho e acompanhamento pode fornecer essa abstração necessária. Considere a ilustração a seguir:

Este é o conceito geral:

1. Opcionalmente, os modelos podem especificar um conjunto de entradas que o usuário pode inserir. Quando um desenvolvedor dispara uma ação específica, ele escolhe um modelo (mesmo que não seja descrito dessa forma) e insere entradas.
2. Uma referência às entradas relacionadas ao modelo torna-se uma solicitação na API da plataforma de desenvolvedor.
3. Depois que uma solicitação é enviada, um componente de roteamento e tratamento de solicitações dentro do orquestrador começa a acompanhar o ciclo de vida da solicitação. O modelo de rotas de componente de roteamento e tratamento de solicitações na solicitação para o provedor da plataforma de desenvolvedor em que o modelo foi originado.
4. O provedor da plataforma de desenvolvedor executaria as etapas apropriadas para sua implementação.
5. [Opcional] O provedor da plataforma de desenvolvedor atualiza a solicitação status à medida que executa a ação.
6. Depois que a solicitação for atendida, o provedor da plataforma de desenvolvedor poderá retornar um conjunto de entidades para adicionar/atualizar no grafo da plataforma de desenvolvedor. Elas podem ser entidades específicas do provedor ou comuns.

Opcionalmente, para dar suporte a interações mais avançadas, você pode permitir que esses provedores de plataforma de desenvolvedor chamem a API da plataforma de desenvolvedor diretamente para obter mais entidades como entradas ou até mesmo solicitar outra ação relacionada.

Embora a solução específica ou um produto que você está avaliando possa variar, isso deve dar uma noção das qualidades a serem buscadas.

Com isso em mente, você desejará ter um provedor de plataforma de desenvolvedor que use uma tarefa geral ou um mecanismo de fluxo de trabalho. Mais especificamente, você desejará que algo faça a ponte do que você montou como parte de Aplicar sistemas de engenharia de software. Um fluxo de trabalho geral ou mecanismo de execução de tarefas em que você provavelmente investirá é seu sistema de CI/CD.

Um exemplo usando o GitHub Actions ou o Azure Pipelines

Vamos examinar brevemente como um GitHub Actions ou o Azure Pipelines como um provedor de plataforma de desenvolvedor funcionaria.

Para GitHub Actions, a chave para fazer esse trabalho é que um provedor de plataforma de desenvolvedor pode se conectar à instância do GitHub especificada e usar a API REST de Ações para disparar um evento de expedição de fluxo de trabalho para disparar uma execução de fluxo de trabalho. Cada fluxo de trabalho pode dar suporte a um conjunto de entradas adicionando uma configuração de workflow_dispatch ao arquivo YAML de fluxo de trabalho. Os gatilhos do Azure DevOps são semelhantes e você também pode usar a API de Pipeline do Azure DevOps para execuções. Você provavelmente verá os mesmos recursos em outros produtos.

Esses fluxos de trabalho/pipelines não precisam estar em repositórios de código-fonte do aplicativo. O conceito seria aproveitar esse fato para fazer algo assim:

1. Os engenheiros de plataforma ou os membros da equipe de DevOps podem manter os fluxos de trabalho/pipelines em um ou mais repositórios centrais aos quais os próprios desenvolvedores não têm acesso, mas o provedor de plataforma do desenvolvedor está configurado para uso. Esse mesmo repositório pode incluir scripts e snippets de IaC que os fluxos de trabalho/pipelines usam.
2. Para permitir que esses fluxos de trabalho/pipelines interajam com o sistema downstream apropriado, operações ou outros membros da sua equipe de engenharia de plataforma podem adicionar os segredos necessários no repositório central. Confira GitHub Actions e a documentação do Azure DevOps para obter detalhes sobre como fazer isso ou você pode optar por centralizar os segredos usando algo como o Azure Key Vault.
3. Esses fluxos de trabalho/pipelines podem seguir um modelo em que publicam entidades resultantes como um artefato de build/implantação (documentos do GitHub, documentos do Azure DevOps).
4. Durante uma execução, o provedor da plataforma de desenvolvedor pode watch o estado do fluxo de trabalho/pipeline e atualizar o ciclo de vida status no orquestrador até que ele seja concluído. Por exemplo, você pode usar web hooks com GitHub Actions e ganchos de serviço com o Azure Pipelines para acompanhar atualizações.
5. Depois de concluído, o provedor pode consumir o artefato publicado para inclusão no grafo da plataforma de desenvolvedor conforme necessário.

Por fim, você pode configurar esse provedor de plataforma de desenvolvedor para gerar um conjunto de modelos no grafo da plataforma de desenvolvedor que referenciam o repositório e o fluxo de trabalho/pipeline apropriados, juntamente com entradas para uma determinada tarefa.

A melhor coisa sobre como usar seu sistema de CI/CD é que eles geralmente são configurados para dar suporte à execução de CLIs arbitrários, portanto, você não precisa de uma integração exclusiva de primeira classe para tudo o que você faz. Você pode adicioná-los ao longo do tempo conforme necessário.

Muito do que é descrito neste exemplo aplica como outros tipos de provedores podem funcionar. Também é importante observar que o uso de GitHub Actions ou Azure Pipelines nesse contexto não exige que você também os use para seus pipelines de CI/CD reais.

Outros exemplos

Aqui estão alguns exemplos de outros tipos de provedores de plataforma de desenvolvedor que podem processar modelos.

Exemplo	Descrição
Operações de controle do código-fonte	Em alguns casos, talvez seja necessário criar ou atualizar um repositório, enviar uma PR ou executar outra operação relacionada ao controle do código-fonte. Embora os mecanismos de fluxo de trabalho assíncronos gerais possam gerenciar esses tipos de operações, ser capaz de executar operações básicas do Git sem uma pode ser útil.
Provisionadores de infraestrutura	Embora GitHub Actions e o Azure Pipelines funcionem bem para gerenciar o provisionamento de infraestrutura, você também pode optar por integrações mais diretas. Um provedor dedicado pode simplificar a instalação e evitar sobrecargas. Serviços como Ambientes de Implantação do Azure ou Terraform Cloud estão mais diretamente focados em habilitar o provisionamento baseado em modelo de IaC e com segurança e segurança. Outros exemplos podem incluir itens como criar namespaces do Kubernetes para aplicativos em clusters compartilhados ou usar git com fluxos de trabalho do GitOps usando Flux ou Argo CD como um tipo específico de provedor. Modelos ainda mais centrados no aplicativo, como o projeto experimental de incubação de OSS Radius com seus próprios CLIs, podem ter seus próprios provedores de plataforma de desenvolvedor ao longo do tempo. O importante é procurar e planejar a extensibilidade para que você possa se adaptar.
Scaffolding/propagação de aplicativo	Os modelos de aplicativo são uma parte importante de onde a engenharia de plataforma lidera ao longo do tempo. Você pode dar suporte ao mecanismo de modelo de sua escolha fornecendo um provedor de plataforma de desenvolvedor dedicado que foi projetado para não apenas estruturar uma árvore de origem do aplicativo, mas também criar e enviar conteúdo por push para um repositório de código-fonte e adicionar as entidades resultantes ao grafo. Cada ecossistema tem sua própria preferência de scaffolding de aplicativo, seja Yeoman, cookiecutter ou algo parecido com o Azure Developer CLI, portanto, o modelo de provedor aqui pode permitir que você dê suporte a mais de uma de suas mesmas interfaces. Aqui novamente, é a extensibilidade que é a chave.
Processos manuais	Seja gerando automaticamente uma PR para aprovação manual ou etapas manuais de fluxo de trabalho para personas não desenvolvedores responderem usando algo como o Power Platform, o mesmo modelo baseado em modelo pode ser usado em um provedor de plataforma de desenvolvedor. Você pode até mesmo passar para etapas mais automatizadas ao longo do tempo.

Embora talvez você não precise que todos esses provedores iniciem, você pode ver como a extensibilidade por meio de algo como um provedor de plataforma de desenvolvedor pode ajudar seus recursos de automação a crescer ao longo do tempo.

Usuários e equipes

A engenharia de plataforma é inerentemente um caso de vários sistemas, por isso é importante planejar como uma base de autoatendimento deve lidar com os problemas mais desafiadores com a integração desses sistemas. Nesta seção, abordaremos uma estratégia para enfrentar desafios comuns com identidade, usuários e equipes.

Primeiro, considere estas duas recomendações:

Recomendação	Descrição
Integrar a API da plataforma de desenvolvedor diretamente ao seu provedor de identidade para obter a segurança ideal	Para proteger a API da plataforma de desenvolvedor, recomendamos a integração direta com um provedor de identidade, como Microsoft Entra ID dada a identidade robusta e os recursos de RBAC (controle de acesso baseado em função) do Entra ID. Há muitas vantagens em usar diretamente os SDKs e APIs nativos de um provedor de identidade (por exemplo, por meio da ID do MSAL Entra) em vez de por meio de uma abstração. Você pode impulsionar a segurança de ponta a ponta e contar com o mesmo modelo RBAC durante todo o processo, garantindo que as políticas de acesso condicional sejam continuamente avaliadas (em vez de apenas no momento da entrada).
Usar integrações de grupo de provedores de identidade e logon único em sistemas downstream	Suas integrações de SSO (logon único) devem usar o mesmo provedor de identidade e locatário que você está usando para sua API da plataforma de desenvolvedor. Além disso, aproveite o suporte para que protocolos como o SCIM conectem em grupos de provedores de identidade (como grupos do AD). A associação desses grupos de provedores de identidade em permissões de sistema downstream nem sempre é automática, mas, no mínimo, você pode associar manualmente a identificação de grupos de provedores aos conceitos de agrupamento de cada ferramenta sem gerenciar manualmente a associação posteriormente. Por exemplo, você pode combinar o suporte do EMU ( Enterprise Managed User ) do GitHub, além de aproveitar manualmente a capacidade de vincular grupos de provedores de identidade às equipes do GitHub. O Azure DevOps tem recursos semelhantes.

Em seguida, criaremos com base nessas recomendações para criar um modelo para lidar com problemas mais desafiadores nesse espaço.

Estabelecer o conceito de uma equipe além de um único grupo de provedores de identidade

À medida que sua jornada de engenharia de plataforma continua, você provavelmente achará que os grupos de provedores de identidade são ótimos para gerenciar a associação, mas que vários grupos realmente precisam se unir para formar o conceito de uma equipe para RBAC (controle de acesso baseado em função) e agregação de dados.

No contexto da engenharia de plataforma, definimos uma equipe como um conjunto de pessoas em diferentes funções que estão trabalhando juntas. Para agregação de dados, a ideia de uma equipe de várias funções é fundamental para alimentar a descoberta e acumular informações em locais como painéis de relatórios. Por outro lado, um grupo é um conceito de provedor de identidade geral para um conjunto de usuários e foi projetado com a ideia de adicionar várias pessoas a uma função específica, em vez de ao contrário. Com o RBAC, uma equipe, portanto, pode se relacionar com vários grupos de provedores de identidade por meio de diferentes funções.

A origem dos dados da equipe pode vir de alguns lugares diferentes. Por exemplo, se você estiver usando as equipes como padrão de código (TaC), um provedor de plataforma de desenvolvedor poderá watch para alterações de arquivo em um repositório e armazená-las em cache em um repositório de metadados de equipe e perfil de usuário. Ou você pode se integrar diretamente a algo como um Projeto do Centro de Desenvolvimento do Azure que já tem esses constructos principais do RBAC disponíveis.

Estabelecer um modelo para integração com sistemas downstream no nível da equipe ou do usuário

Embora algumas ferramentas/serviços de desenvolvedor e operações integrem e usem nativamente os conceitos do provedor de identidade diretamente, muitos abstrairão isso em sua própria representação de um grupo ou usuário (mesmo com SSO). Além de habilitar o acesso entre ferramentas, essa realidade também pode representar problemas para a agregação de dados. Especificamente, você pode descobrir que as APIs no sistema downstream usam seus próprios identificadores em vez de identificadores de provedor de identidade (exemplo: a ID do objeto na ID do Entra não é usada diretamente). Isso dificulta a filtragem e a associação de dados no nível do usuário ou da equipe, a menos que você possa mapear entre diferentes IDs.

Abordando diferenças de nível de equipe e grupo

Padrões como o TaC podem permitir que você armazene e acesse relações entre a equipe ou os identificadores de grupo de cada sistema para que você possa mapear entre eles. Para recapitular, um repositório Git seguro e auditável se torna a origem de uma equipe e os PRs fornecem uma interface do usuário controlada para fazer atualizações. Os sistemas de CI/CD podem atualizar os sistemas downstream e persistir as relações de identificador relacionadas para a equipe usada para fazer isso.

Por exemplo, isso permite que as seguintes relações sejam armazenadas em chamadas à API:

Se você preferir usar uma fonte de dados diferente de arquivos em um repositório de suas equipes, esse mesmo conceito geral pode ser aplicado usando o orquestrador da plataforma de desenvolvedor para realizar a mesma coisa. Nesse modelo, um provedor de plataforma de desenvolvedor para a origem dos dados da equipe pode disparar um evento de atualização de equipe que todos os outros provedores recebem e agem conforme apropriado.

Abordando desafios de ID de usuário

Outro desafio relacionado para acesso e agregação de dados são as diferenças de ID de usuário. Assim como no caso da equipe, se você usar uma integração sistema a sistema para consultar dados sobre um usuário, não poderá supor que a ID nativa dos provedores de identidade (por exemplo, ID de objeto para ID do Entra) dê suporte a uma determinada API. Novamente, armazenar um mapeamento para uma ID de usuário que está acessando dados por meio da API da plataforma de desenvolvedor pode ajudar. Por exemplo, considere o GitHub:

Para cada sistema, se você puder fazer uma pesquisa de uma ID de usuário em outro sistema por meio de uma API sem um token de usuário, um determinado provedor de plataforma de desenvolvedor poderá gerar esse mapeamento em tempo real. Em alguns casos, isso pode ficar complicado, pois talvez seja necessário executar essa operação em massa e armazenar em cache os resultados para referência para manter o desempenho.

Fazer fallback usando vários tokens de usuário

Para situações em que os provedores precisam acessar dados no nível do usuário sem uma maneira de fazer a tradução de ID de usuário que funcionaria, a API da plataforma de desenvolvedor pode ser configurada para gerenciar vários tokens de usuário. Por exemplo:

1. A API da plataforma de desenvolvedor pode dar suporte a um cache de tokens de usuário específicos do provedor para uso com sistemas downstream.
2. Qualquer interações com um determinado provedor disparado pela API incluiria no token de usuário do provedor, se disponível.
3. Para lidar com o caso em que nenhum token de usuário estava disponível, o provedor dispararia um fluxo OAuth para obter um.
4. Para começar, a API da plataforma de desenvolvedor passaria um URI de autenticação para um fluxo OAuth com um URI de redirecionamento que foi passado para o provedor. O URI passado incluiria um código nonce/uso único.
5. Em seguida, a API retorna uma resposta "não autenticada" com o URI.
6. Qualquer experiência de usuário pode usar esse URI para impulsionar o fluxo de autenticação apropriado em um navegador.
7. Depois que o redirecionamento acontecer, a plataforma de desenvolvedor receberá o token de usuário necessário e o armazenará em cache para referência futura junto com a ID de usuário.
8. Em seguida, o cliente pode repetir a chamada à API, o que teria êxito.

Esse conceito descreve uma maneira de lidar com autenticação complicada, pois você pode reutilizar IDs sempre que possível e não precisa manter URIs de redirecionamento separados por sistema downstream.

Agregando dados e fornecendo recursos extras

Usar links profundos com reconhecimento de contexto para ferramentas e sistemas de relatórios

Até este ponto, falamos sobre o aspecto de automação do espaço do problema. Isso por si só pode percorrer um longo caminho, pois sua interface do usuário pode usar valores nas entidades retornadas durante a automação para criar links profundos em outros sistemas para a equipe.

Mesmo quando não relacionados à automação, os provedores de plataforma de desenvolvedor podem emitir qualquer tipo de necessidade de entidade. No entanto, você geralmente não deseja trazer todos os dados detalhados em toda a sua plataforma de desenvolvedor interno para o grafo da plataforma de desenvolvedor. Painéis em soluções de observabilidade como Grafana, Prometheus, DataDog ou inteligência de código em produtos como o SonarQube e recursos nativos em pacotes de DevOps, como GitHub e Azure DevOps, são todos muito capazes. Em vez disso, a melhor abordagem geralmente é criar links profundos nesses outros sistemas. Suas entidades podem fornecer informações suficientes para criar links sem conter diretamente informações detalhadas, como conteúdo de log.

Para casos em que você deseja agregar e resumir dados entre ferramentas ou precisar gerar métricas personalizadas, as soluções de relatórios do Power BI ou do Microsoft Fabric podem ser sua próxima porta de chamada. Para mesclar dados de equipe, você pode se conectar ao banco de dados da Sua Fundação ou passar por uma API da plataforma de desenvolvedor. Por exemplo, conforme descrito em Planejar e priorizar, um local em que você pode querer uma dashboard personalizada é medir o sucesso de sua plataforma de desenvolvedor interna.

Seja seletivo a cada experiência extra que você criar

Embora possa ser interessante recriar recursos existentes em algo como um portal comum, lembre-se de que você também precisará mantê-lo. Essa é a área em que seguir uma mentalidade de produto é importante. Interfaces de estilo de painel são fáceis de conceber e entender, mas seus desenvolvedores podem encontrar mais valor em outro lugar.

Dito isto, o modelo aqui permite que você use dados agregados no grafo da plataforma de desenvolvedor para criar experiências personalizadas do usuário. As entidades devem ter suporte interno para que possam se vincular a um usuário ou equipe. Isso permite que a API da plataforma de desenvolvedores escopo a saída (juntamente com o uso de indexação e cache).

No entanto, mesmo quando você precisa criar uma experiência de usuário personalizada em vez de um link profundo, extrair todos os dados para o grafo da plataforma de desenvolvedor normalmente ainda não é a melhor abordagem. Por exemplo, considere uma situação em que talvez você queira exibir logs em sua experiência de usuário que já tenha uma casa bem definida e gerenciada. Use informações nas entidades relacionadas para ajudar sua experiência do usuário a coletar informações diretamente de sistemas downstream.

Para começar, talvez seja necessário usar uma integração sistema a sistema para se conectar, mas depois de implementar um dos modelos descritos em usuários e equipes, você pode usar quaisquer IDs de usuário/equipe downstream armazenadas ou tokens de autenticação de usuário, se necessário.

Aqui estão alguns exemplos de experiências comuns a serem consideradas:

Exemplo	Descrição
Descoberta e exploração	Como disse um profissional de engenharia de plataforma, "O que desacelera os projetos é a comunicação, não as habilidades de desenvolvedor". –Daniel, Engenheiro de Nuvem, Fortune 500 Media Company. Como o software é um esporte de equipe, criar uma interface do usuário para ajudar a descobrir equipes e as entidades que eles possuem normalmente é uma das primeiras coisas a serem abordadas. A pesquisa, a descoberta e os documentos entre equipes ajudam a promover a reutilização e a colaboração de ajuda para fornecimento ou suporte interno. As equipes também se beneficiam de ter uma loja única para encontrar coisas que possuem, incluindo ambientes, repositórios e outros recursos, como documentos.
Registro manual de ambientes ou recursos	Embora muitas coisas possam ser provisionadas e rastreadas por meio do orquestrador da plataforma de desenvolvedores, talvez você também queira registrar recursos ou ambientes que já existem ou ainda não foram automatizados. Um provedor simples que recebe informações de um repositório git e adiciona informações ao gerenciamento de recursos/ambiente pode ser útil aqui. Se você já tiver um catálogo de software, isso também se tornará uma maneira de integrá-lo ao modelo.
Um catálogo de API	O acompanhamento de APIs que os desenvolvedores devem usar pode percorrer um longo caminho. Se ainda não tiver algo, você pode até mesmo começar com um repositório Git simples com uma série de arquivos que representam APIs, seus status, usar PRs para gerenciar seu fluxo de trabalho de aprovação. Eles podem ser adicionados ao grafo da plataforma de desenvolvedor para que possam ser exibidos ou associados a outras entidades. Para recursos mais robustos, você pode integrar algo como o Centro de API da Microsoft ou outro produto.
Conformidade de licença	Em alguns casos, talvez você também queira fornecer visibilidade sobre a conformidade de licenças de software e o consumo de estações. As plataformas de desenvolvedor também podem adicionar a automação necessária para consumir estações, mas mesmo que as estações sejam atribuídas manualmente (por exemplo, por meio de um processo de PR em um repositório Git), visibilidade do desenvolvedor sobre o que eles têm (e a capacidade do administrador de ver em tudo).
Uma exibição centrada no aplicativo do Kubernetes	Quando você usa um cluster compartilhado do Kubernetes, pode ser difícil para os desenvolvedores encontrar e entender o estado de seus aplicativos por meio da UX de administrador de cluster. Diferentes organizações optaram por lidar com esse problema de forma diferente, mas usar um namespace para representar um aplicativo é uma maneira conhecida de fazer isso. A partir daí, você pode usar entidades para estabelecer associações entre o namespace do aplicativo no cluster e uma equipe e criar uma exibição mais focada no desenvolvedor de status para o aplicativo e fornecer links profundos para outras ferramentas ou interfaces do usuário da Web.

Experiências do usuário

Diferentes funções em sua organização terão ferramentas ou serviços que representam um centro de gravidade para seu trabalho diário. A atração desses sistemas pode dificultar que novas experiências do usuário fora desses centros de gravidade ganhem força. Em um mundo perfeito, desenvolvedores, operações e outras funções podem continuar a trabalhar em um ambiente que faz sentido para eles , muitas vezes aqueles que já estão usando.

Com isso em mente, planejar várias interfaces do usuário à medida que você avança em sua jornada de engenharia de plataforma é uma boa ideia. Isso também pode fornecer uma oportunidade para iniciar simples, provar valor e crescer em direção a interfaces mais complexas à medida que a necessidade surge.

Integrar o que você tem

Se você leu os artigos Aplicar sistemas de engenharia de software e Refinar plataforma de aplicativos , provavelmente identificou os sistemas que deseja continuar a usar. Em ambos os casos, avalie se você pode aprimorar e estender o que tem antes de começar a criar novas experiências do zero. (Pergunte-se, as pessoas reagirão melhor a outra nova experiência do usuário ou a uma versão aprimorada de algo que elas têm agora?)

Algumas das ferramentas, utilitários ou aplicativos Web que você deseja continuar usando serão personalizadas e são boas candidatas para aprimoramento. Mas não se esqueça de prestar atenção se suas ferramentas e serviços favoritos têm um modelo de extensibilidade que você pode usar. Você terá muito benefício de começar por lá. Isso pode eliminar dores de cabeça de manutenção e segurança e permitir que você se concentre no problema que está tentando resolver

Por exemplo, você pode estender as seguintes superfícies que já está usando:

• Editores e IDEs.
• Seu pacote de DevOps.
• As CLIs também são cada vez mais extensíveis.
• Ambientes baixos/sem código, como o Power Pages.

Cada um pode fornecer um ponto de partida melhor para uma determinada função do que algo que você configurou do zero, já que eles são centros de gravidade existentes. Ter uma API de plataforma de desenvolvedor comum como linha de base permitirá que você troque itens, experimente e mude ao longo do tempo.

Considere as extensões do editor da Web para criar um portal do desenvolvedor

Se você estiver procurando uma experiência baseada na Web para desenvolvedores, tenha em mente que uma tendência recente são versões baseadas na Web de editores e IDEs. Muitos, como aqueles que usam o VS Code, têm suporte para extensão. Com o VS Code, tudo o que você cria para essas experiências da Web é convertido localmente para um benefício duplo.

Além de serviços como o GitHub Codespaces, vscode.dev é uma versão da Web gratuita do editor do VS Code sem computação, mas inclui suporte para determinados tipos de extensões , incluindo aqueles que usam modos de exibição da Web para interface do usuário personalizada.

Mesmo que seus desenvolvedores não estejam usando o VS Code em si, os padrões de experiência do usuário são bem conhecidos e podem ser encontrados em outras ferramentas de desenvolvedor. Usar vscode.dev pode fornecer uma base conveniente e familiar baseada na Web para experiências de desenvolvedor, além da própria ferramenta.

Eles podem atuar como um portal focado no desenvolvedor em uma forma familiar que também pode se traduzir para uso local.

ChatOps

Outra oportunidade que geralmente é ignorada é implementar uma interface ChatOps. Considerando o aumento de interfaces baseadas em chat devido ao aumento de produtos de IA, como ChatGPT e GitHub Copilot, comandos de ação ou comandos de barra podem fornecer uma maneira útil de disparar fluxos de trabalho de automação, marcar status e muito mais. Considerando que a maioria das plataformas de CI/CD do aplicativo tem suporte pronto para uso para sistemas como Microsoft Teams, Slack ou Discord, essa pode ser uma maneira natural de se integrar a outros desenvolvedores de interface do usuário e funções de operações relacionadas usam todos os dias. Além disso, todos esses produtos têm um modelo de extensibilidade.

Investir em um novo portal do desenvolvedor

Supondo que você não tenha um portal ou interface existente que deseja usar como base, você pode decidir criar um novo portal do desenvolvedor. Pense nisso como um destino em vez de um ponto de partida. Se você ainda não tiver uma equipe de desenvolvimento trabalhando com você, iniciar esse esforço é o momento de fazer isso. Cada organização é diferente, portanto, não há uma resposta única para o que deve estar nesse tipo de experiência. Como resultado, não há uma resposta de fato para um produto pré-empacotado que você possa criar e usar no estado em que se encontra para algo assim hoje.

Para opções personalizadas internas auto-hospedadas, as estruturas gerais do portal da Web não são novas e suas equipes de desenvolvimento podem já estar usando uma que você pode explorar. Se você estiver tentando obter algo na frente de seus usuários para obter comentários antecipados, você pode até começar com algo tão simples quanto o Power Pages de baixo código para se conectar à API comum da plataforma de desenvolvedor.

Os esforços mais recentes do portal do desenvolvedor são mais opinativos. Por exemplo, Backstage.io é um kit de ferramentas personalizado do portal do desenvolvedor criado inicialmente para atender às necessidades do Spotify. Ele inclui uma CLI para ajudar a inicializar sua árvore de origem, assim como create-react-app faz para React.js.

Como um kit de ferramentas do portal, ele requer trabalho para se atualizar e a personalização requer conhecimento de TypeScript, Node.js e React. No entanto, a grande coisa sobre isso é que, como um kit de ferramentas, você pode mudar quase qualquer coisa. Ele também tem seu próprio catálogo de software e mecanismo de modelagem, mas seu uso não é necessário e tem uma maneira bem definida de trazer novos códigos de terceiros 1^e3 chamados plug-ins.