Criar uma fundação de autoatendimento para desenvolvedores

Depois de ter uma boa compreensão do seu objetivo para seus sistemas de engenharia, você pode criar experiências de autoatendimento para desenvolvedores mais sofisticadas. Uma experiência de autoatendimento do desenvolvedor baseia-se em conceitos, padrões e componentes.

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. O modelo de experiência de autoatendimento do desenvolvedor pode ser composto por uma combinação de produtos domésticos, off-the-shelf e de software livre. Produtos ou kits de ferramentas do portal de software livre, como Backstage.io , podem usar termos diferentes para alguns elementos do modelo descrito aqui, mas o modelo ainda pode ajudar a orientá-lo.

Automatizar fluxos de trabalho, agregar dados, iniciar simples e expandir gradualmente

Seu objetivo é habilitar o autoatendimento com balizamentos por meio de execução e provisionamento de tarefas controlados e gerenciados, juntamente com visibilidade centralizada. As áreas mais valiosas para se concentrar são aquelas que são entediantes 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 do privilégio mínimo sem obrigar os desenvolvedores a passar por um processo manual de central de serviços.

Embora você possa optar por estender seu pacote de DevOps para atender a essas necessidades, provavelmente você 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 podem precisar mudar. O problema principal é que seus padrões são um alvo móvel. Como um profissional de engenharia de plataforma afirmou:

As dificuldades envolvem padronização... e lidar com 'abandonware' (software abandonado)... 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 da DevOps, grande empresa de logística

Mudar rapidamente 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á permitir a experimentação controlada em que as equipes designadas possam experimentar novas tecnologias, estratégias de implantação e assim por diante, seguidas por adoção deliberada e uma distribuição incremental.

Geralmente, as experiências de autoatendimento se enquadram em duas categorias primárias: automação e agregação de dados.

Embora a agregação de dados crie boas experiências do usuário, a automação é mais importante:

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

Em seu percurso de engenharia de plataforma, você identificou problemas potencialmente 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ê trabalha com mais de um sistema para impulsionar sua automação, algum nível de agregação de dados é útil para ajudar a controlar as solicitações automatizadas e os resultados associados. 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 auditoria, governança e redução de desperdícios (por exemplo, ambientes não utilizados).

A automação de itens como o provisionamento de infraestrutura pode ser feita usando integrações de 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 seu 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 uma automação desde o início.

Comece simples reutilizando investimentos existentes, como seus sistemas de engenharia ou um portal interno, vá para a criação de CLIs, páginas da Web básicas ou até mesmo painéis do Power Pages, do Power BI ou do Microsoft Fabric e expanda conforme a necessidade surge. Ter uma API consistente que a UX usa pode ajudá-lo a dar suporte a várias interfaces ao longo do tempo à medida que suas necessidades e preferências mudam.

Componentes da plataforma de autoatendimento do desenvolvedor: API, grafo, orquestrador, provedores e metadados

Considere os fundamentos do autoatendimento do desenvolvedor:

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

Esses componentes fundamentais permitem que você use e troque diferentes blocos de construção ao longo do tempo.

Preciso criar tudo isso para começar?

Não. Primeiro, este é um modelo conceitual para ajudá-lo a pensar sobre o que uma base como esta deve ser capaz de fazer, uma vez que ela está concluída. 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 misturando-as com outras ferramentas. Você também pode omitir aspectos porque o desenvolvimento do cliente sugere que é simplesmente uma prioridade menor. Comece com o que você tem e cresça.

API da plataforma de desenvolvedores

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

Essa API atua como uma importante camada de segurança e autenticação limitando o acesso a APIs subjacentes brutas em outros sistemas a dados e operações mais específicas e controladas. A API fornece acesso à sua própria representação de um perfil de usuário, à função de alto nível de um usuário dentro da 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, você deve criar ou identificar sistemas que seguem um modelo de provedor extensível para introduzir a funcionalidade na API. A ideia é que as principais funcionalidades, como automação e agregação de dados, sejam fornecidas interagindo com componentes plugáveis com interfaces bem definidas. Esse acoplamento flexível ajuda você a conectar o que você precisa incrementalmente e melhora a manutenção, pois você pode testar a funcionalidade independentemente 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 força 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 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, examine qualquer código de provedor e limite a área de superfície que um determinado provedor pode acessar em sua plataforma de desenvolvedor, uma abordagem pluggável pode ajudá-lo a fazer mais dimensionando o esforço em uma parte mais ampla da organização.

Principais conceitos do provedor de plataforma de desenvolvedor

Entities

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

• Exibindo 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.
• Tornando visíveis as informações de manutenção/propriedade para descoberta e colaboração
• Tornando mais dados disponíveis 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 desenvolvedores fora da equipe de plataforma de desenvolvedor interno principal 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 base as gerencie. Algumas propriedades a serem consideradas incluem:

• Identificador exclusivo
• Nome
• Provedor de origem
• Associações opcionais para:
  • Usuário proprietário
  • Equipe responsável
  • 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). Incorporar o 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 em equipe, descobrir com quem falar sobre uma entidade rapidamente se tornará fundamental para reutilização, suporte e interiorização.

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:

• Environments
• Recursos
• APIs
• Repositórios
• Components
• Tools

Eles geralmente devem estar em um alto nível, como você colocaria no contexto do modelo C4 ou, no máximo, em 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. A entidade pode direcionar-se para níveis de detalhe mais baixos 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 sã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 template neste contexto difere da ideia de entidades ao ser destinado a conduzir uma ação. Cenários de exemplo incluem provisionamento de infraestrutura, criação de um repositório e outros processos de execução longa. 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. Elas podem variar de qualquer coisa, como nomear o recurso a 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 e fluxo de trabalho
• Pipeline de implantação e modelos de fluxo de trabalho
• Scripts parametrizados
• Fluxos parametrizados do Power Automate (por 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. Elas podem variar de modelos do Terraform ou Templates do ARM, até Helm Charts, fluxos de trabalho parametrizados do GitHub Actions 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 endpoint HTTP parametrizado. Um provedor de plataforma de desenvolvedor deve fornecer informações suficientes sobre cada tipo de modelo para que eles possam ser referenciados e quaisquer opções expostas para uso em experiências do usuário. Porém, os próprios modelos podem ser armazenados na localização mais adequada para os seus casos de uso.

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

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 mantidos 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 utilizado com entidades comuns às quais vários provedores podem contribuir. Por exemplo, uma lista de APIs pode vir de um produto como o Centro de API do Azure, mas você também pode querer integrar automaticamente implantações e ambientes de execução de seus sistemas de implantação contínua. Ao longo do tempo, você pode alternar entre sistemas de implantação diferentes 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 das experiências do usuário que se baseiam nesse grafo pode aproveitar uma API comum para a descoberta, busca, 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 desenvolvimento

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, um mecanismo de fluxo de trabalho ou outro orquestrador para fazer isso. É uma das peças 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.

Você pode usar o GitHub Actions, o Azure Pipelines ou outro mecanismo de fluxo de trabalho como seu orquestrador. Este é 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 vai querer poder escolher diferentes motores de execução de fluxo de trabalho e tarefas ao longo do tempo sem precisar de uma mudança imediata. 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 direcionar funções fora da equipe de desenvolvimento, como contas a pagar ou um administrador de licenças. 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, onde configurar algo tão capaz quanto GitHub Actions ou Azure Pipelines não é necessário ou econômico para escalar.

Felizmente, expandir a ideia de um provedor de plataforma de desenvolvedor para incluir processos de automação de disparo e monitoramento pode fornecer a abstração necessária. Considere a ilustração a seguir:

Aqui está o conceito geral:

• Os modelos podem, opcionalmente, 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 insira quaisquer entradas.
• Uma referência às entradas relacionadas ao modelo torna-se uma solicitação na API da plataforma de desenvolvedor.
• Depois que uma solicitação é enviada, um componente de roteamento e tratamento de solicitação dentro do orquestrador começa a acompanhar o ciclo de vida da solicitação. O componente de roteamento e tratamento de solicitações direciona o modelo na solicitação para o provedor da plataforma de desenvolvedor onde o modelo se originou.
• Em seguida, o provedor de plataforma do desenvolvedor executa as etapas apropriadas para sua implementação.
• (Opcional) O provedor da plataforma de desenvolvedor atualiza o status da solicitação enquanto executa a ação.
• Depois que a solicitação for atendida, o provedor de plataforma do desenvolvedor poderá retornar um conjunto de entidades para adicionar ou atualizar no grafo da plataforma de desenvolvedor. Elas podem ser entidades específicas ou comuns do provedor.

Opcionalmente, para dar suporte a interações mais avançadas, os provedores de plataforma de desenvolvedor podem chamar a API da plataforma de desenvolvedor diretamente para obter mais entidades como entradas ou até mesmo solicitar outra ação relacionada.

Escolha um provedor de plataforma de desenvolvedor que use uma tarefa geral ou um mecanismo de fluxo de trabalho. Mais especificamente, você deseja que algo faça a ponte entre o que você montou como parte da aplicação de sistemas de engenharia de software. Um fluxo de trabalho geral ou mecanismo de execução de tarefas no qual investir é um sistema de CI/CD.

Um exemplo usando o GitHub Actions ou o Azure Pipelines

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

Para o GitHub Actions, a chave para fazer isso funcionar é que um provedor de plataforma de desenvolvedor possa se conectar à instância do GitHub especificada e usar a API REST de Ações para disparar um evento de despacho de fluxo de trabalho para iniciar uma execução de fluxo de trabalho. Cada fluxo de trabalho pode dar suporte a um conjunto de entradas adicionando uma configuração 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 ou pipelines não precisam estar em repositórios de código-fonte do aplicativo. O conceito seria aproveitar esse fato para fazer algo assim:

• Os engenheiros de plataforma ou os membros da equipe do 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.
• Para permitir que esses fluxos de trabalho/pipelines interajam com o sistema downstream apropriado, ops ou outros membros da sua equipe de engenharia de plataforma podem adicionar os segredos necessários no repositório central. Consulte a documentação do GitHub Actions e 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.
• Esses fluxos de trabalho/pipelines podem seguir um modelo em que publicam todas as entidades resultantes como um artefato de build/implantação (documentos do GitHub, documentos do Azure DevOps).
• Durante uma execução, o provedor da plataforma do desenvolvedor pode observar o estado do fluxo de trabalho/pipeline e atualizar o estado do ciclo de vida no orquestrador até que ele seja concluído. Por exemplo, você pode usar ganchos da Web com o GitHub Actions e ganchos de serviço com o Azure Pipelines para acompanhar as atualizações.
• Depois de concluído, o provedor poderá consumir o artefato publicado para inclusão no gráfico da plataforma de desenvolvedores, 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 desenvolvedores que fazem referência ao repositório e fluxo de trabalho/pipeline apropriados, juntamente com entradas para uma determinada tarefa.

A melhor coisa em usar um 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á-las ao longo do tempo conforme necessário.

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

Outros exemplos

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

Embora talvez você não precise de todos esses provedores para começar, 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. Aqui está uma estratégia para lidar com desafios comuns com identidade, usuários e equipes.

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 descobrirá 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 e agregação de dados.

No contexto da engenharia de plataforma, definimos uma equipe como um conjunto de pessoas em diferentes funções que trabalham juntas. Para agregação de dados, a ideia de uma equipe multirrole é essencial para potencializar a descoberta e agregar 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 do contrário. Com o RBAC, uma equipe, portanto, pode se relacionar com vários grupos de provedores de identidade por meio de funções diferentes.

A origem dos dados da equipe pode vir de alguns locais diferentes. Por exemplo, se você estiver usando o padrão equipes como código (TAC), um provedor de plataforma de desenvolvimento poderá monitorar as 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 para desenvolvedores e operações integrem e utilizem diretamente os conceitos de provedor de identidade, muitos transformam 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 apresentar problemas de agregação de dados. Especificamente, você pode descobrir que as APIs de sistemas downstream usam seus próprios identificadores em vez de identificadores de provedor de identidade (por exemplo, o ID do objeto no Entra ID não é usado diretamente). Isso dificulta a filtragem e a associação de dados de nível de usuário ou equipe, a menos que você possa mapear entre diferentes IDs.

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

Padrões como o TaC podem permitir que você armazene e acesse relações entre os identificadores de equipe ou grupo de cada sistema para que você possa mapeá-los. 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 então atualizar os sistemas downstream e persistir as relações de identificadores relacionadas para as equipes que os utilizaram para isso.

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

Se você preferir usar uma fonte de dados diferente dos arquivos em um repositório das suas equipes, esse mesmo conceito geral pode ser aplicado utilizando o orquestrador da plataforma de desenvolvimento para alcançar a mesma finalidade. Nesse modelo, um provedor de plataformas para desenvolvedores para a origem dos dados da equipe pode disparar um evento de atualização de equipe que todos os outros provedores recebem e tomam as medidas adequadas.

Solucionar desafios de ID do usuário

Outro desafio relacionado para acesso e agregação de dados são as diferenças de ID do 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 a ID do Entra) dê suporte a uma determinada API. Aqui novamente, armazenar um mapeamento para uma ID de usuário que acessa 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.

Recorrer ao uso de 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 eficaz de traduzir o ID de usuário, a API da plataforma de desenvolvimento pode ser configurada para gerenciar múltiplos tokens de usuário. Por exemplo:

• 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.
• Quaisquer interações com um determinado provedor disparadas pela API incluirão no token de usuário do provedor, se disponível.
• Para lidar com o caso em que nenhum token de usuário estava disponível, o provedor dispararia um fluxo OAuth para obter um.
• Para começar, a API da plataforma de desenvolvedor repassaria um URI de autenticação para um fluxo OAuth com um URI de redirecionamento que foi passado para o provedor. A URI passada incluiria um código nonce/código de uso único.
• Em seguida, a API retorna uma resposta não autenticada com o URI.
• Qualquer interface de usuário pode usar o URI para conduzir o fluxo de autenticação apropriado em um navegador.
• 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, juntamente com a ID do usuário.
• O cliente poderia tentar novamente 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 separadas por sistema downstream.

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

Até agora, falamos sobre o aspecto de automação do espaço problemático. Isso por si só pode percorrer um longo caminho, já que 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 desenvolvimento podem emitir qualquer tipo de entidade necessária. No entanto, geralmente, você não deseja integrar todos os dados detalhados da sua plataforma de desenvolvedor interna ao gráfico da plataforma de desenvolvedores. 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 o GitHub e o Azure DevOps, são todos capazes. Em vez disso, a melhor abordagem geralmente é criar links profundos para esses 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 conduzir métricas personalizadas, as soluções de relatórios Power BI ou Microsoft Fabric podem ser sua próxima escolha. Para mesclar dados de equipe, você pode se conectar ao banco de dados da sua fundação ou passar por uma API de plataforma de desenvolvedor. Por exemplo, conforme descrito em Plano e prioridade, um lugar onde você pode querer um painel personalizado é medir o sucesso da sua plataforma de desenvolvedor interna.

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

Embora possa ser atraente recriar recursos existentes em algo como um portal comum, tenha em mente que você também precisará mantê-lo. Essa é a área em que seguir uma mentalidade de produto é importante. As interfaces no estilo dashboard 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 desenvolvedores 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 definir o escopo da saída da API para a sua plataforma de desenvolvedores, e utilizar indexação e cache.

No entanto, mesmo quando você precisa criar um UX personalizado em vez de um link profundo, puxar todos os dados para o grafo da plataforma de desenvolvedores normalmente ainda não é a melhor abordagem. Por exemplo, considere uma situação em que talvez você queira exibir logs em seu UX que já tenha uma casa bem definida e gerenciada. Use informações nas entidades relacionadas para ajudar sua experiência de 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:

Experiências do usuário

Diferentes funções em sua organização têm 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 de usuário à medida que você progride em seu percurso de engenharia de plataforma é uma boa ideia. Isso também pode proporcionar uma oportunidade de iniciar interfaces simples, provar valor e crescer em direção a interfaces mais complexas conforme a necessidade surge.

Integre o que você tem

Se você leu os artigos aplicar sistemas de engenharia de software e refinar a 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 a si mesmo, 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 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 suíte DevOps
• OS CLIs também são cada vez mais extensíveis
• Ambientes de baixo/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 são centros de gravidade existentes. Ter uma API de plataforma de desenvolvedor comum como uma linha de base permite 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 é 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 os Codespaces do GitHub, 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 visões da Web para interface do usuário personalizada.

Mesmo que os desenvolvedores não usem o VS Code em si, os padrões de UX 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 voltado para desenvolvedores em uma forma familiar que também pode se traduzir para uso local.

ChatOps

Outra oportunidade que geralmente é ignorada é implementar uma interface do ChatOps. Considerando o aumento das 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, verificar status e muito mais. Considerando que a maioria das plataformas de CI/CD de aplicativos tem suporte pronto para sistemas como Microsoft Teams, Slack ou Discord, essa pode ser uma maneira natural de se integrar com outros sistemas que os desenvolvedores de interface do usuário e as funções de operações relacionadas usam todos os dias. Além disso, todos esses produtos têm um modelo de extensibilidade.

Investindo em um novo portal de desenvolvedores

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 solução única para o que deve estar nesse tipo de experiência. Como resultado, não há uma resposta padrão para um produto pré-empacotado que você possa ativar e usar tal como está para algo assim hoje.

Para opções auto-hospedadas personalizadas, 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 disponibilizar algo aos seus usuários para obter feedback antecipado, você pode até começar com algo tão simples quanto o Power Pages de baixo código para se conectar à API de uma plataforma comum para desenvolvedores.

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 o create-react-app faz para React.js.

Como um kit de ferramentas do portal, ele requer trabalho para configurar, 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 tudo. Ele também tem seu próprio catálogo de software e mecanismo de modelagem, mas seu uso não é necessário, e é um modo bem definido de integrar novos códigos chamados plugins.

Conteúdo relacionado

• Microsoft Power Pages
• Backstage.io
• Aplicar sistemas de engenharia de software