Projetar uma base de autosserviço para desenvolvedores

Depois de ter uma boa compreensão do seu alvo para seus sistemas de engenharia, você pode criar experiências de autosserviço de desenvolvedor mais sofisticadas. Uma experiência de autosserviço do desenvolvedor é construída sobre uma base de conceitos, padrões e componentes.

Embora você possa não precisar de tudo o que está descrito aqui em sua organização hoje, você deve manter esses conceitos em mente se criar algo personalizado ou avaliar produtos relacionados. Seu modelo de experiência de autosserviço para desenvolvedores pode ser composto por uma combinação de produtos caseiros, prontos para uso e de código aberto. Produtos ou kits de ferramentas de portal de código aberto como Backstage.io podem usar termos diferentes para alguns elementos do modelo descrito aqui, mas o modelo ainda pode ajudar a orientá-lo.

Automatize fluxos de trabalho, agregue dados, comece de forma simples e expanda gradualmente

Seu objetivo é habilitar o autosserviço com guarda-corpos por meio de execução e provisionamento de tarefas controladas e controladas, juntamente com visibilidade centralizada. As áreas que são 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 parte é importante para permitir que você siga o princípio do menor privilégio sem forçar os desenvolvedores através de um processo manual de central de serviços.

Embora você possa optar por estender seu pacote de DevOps para atender a essas necessidades, provavelmente precisará oferecer suporte a várias plataformas de aplicativos ao longo do tempo, e as ferramentas e processos específicos que as suportam também precisarão ser alterados. A questão central é que seus padrões são um alvo em movimento. Como um profissional de engenharia de plataforma afirmou:

As dificuldades envolvem a padronização... e lidar com o software classificado como 'abandonware'... A padronização muitas vezes não é alcançada devido à potencial interrupção dos processos automatizados e à demorada tarefa de identificar as mudanças necessárias. - Martin, engenheiro de DevOps, grande empresa de logística

Mudar rapidamente para um padrão novo ou atualizado normalmente não é viável, e abandonar os processos existentes cria riscos. Sua organização já pode estar usando vários pacotes de DevOps ou diferentes combinações 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, onde as equipes designadas podem 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 e agregação de dados.

Embora a agregação de dados crie boas experiências para o 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 plataformas, empresa multinacional de tecnologia

Em sua jornada de engenharia de plataforma, você identificou problemas potencialmente resolvidos pela automação. Além de reduzir a carga cognitiva e o trabalho 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 fazer 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 rastrear solicitações automatizadas e os resultados associados. Você pode começar ligando a sistemas externos para atender a outras necessidades ou para detalhar detalhes. A agregação e visibilidade de dados também é importante para auditoria, governança e redução de desperdícios (por exemplo, ambientes não utilizados).

A automatização de coisas como o provisionamento de infraestrutura pode ser feita usando integrações de sistema, mas você também pode acionar e facilitar um processo de fluxo de trabalho manual que parece automatizado para o desenvolvedor. Isso é útil nos estágios iniciais da sua plataforma, para novos produtos que você está trazendo para o seu ecossistema ou em áreas que você não automatizou 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 Power Automate que você muda para um fluxo totalmente automatizado ao longo do tempo. Projete tendo a automação em mente desde o início.

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

Componentes da plataforma de autoatendimento do desenvolvedor: API, gráfico, orquestrador, provedores e metadados

Considere os fundamentos do autosserviço do desenvolvedor:

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

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

Tenho que construir tudo isso para começar?

Não. Primeiro, este é um modelo conceitual para ajudá-lo a pensar sobre o que uma fundação como essa deve ser capaz de fazer uma vez concluída. Em segundo lugar, as especificidades da implementação são menos importantes aqui, dado que a API da plataforma do desenvolvedor se torna sua interface chave. A sua implementação inicial pode começar por usar interfaces e classes no seu código para as diferentes camadas descritas ou integrando outros produtos. Você também pode omitir aspetos porque a gestão de clientes sugere que é simplesmente uma prioridade menor. Comece com o que tem e cresça.

API da plataforma do desenvolvedor

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

Essa API atua como uma importante camada de autenticação e segurança, limitando o acesso a APIs subjacentes brutas em outros sistemas a dados e operações mais específicos e controlados. 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 de 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 sigam um modelo de provedor extensível para introduzir funcionalidade na API. A ideia é que funcionalidades-chave como automação e agregação de dados sejam fornecidas interagindo com componentes conectáveis com interfaces bem definidas. Esse acoplamento solto ajuda você a conectar o que você precisa incrementalmente e melhora a capacidade de manutenção, uma vez que você pode testar a funcionalidade independentemente do resto da fundação.

Também é uma maneira importante de habilitar uma mentalidade de fonte interna escalável para sua plataforma. Normalmente, os esforços internos de sourcing em torno da engenharia da plataforma não conseguem ganhar tração devido a desafios com a manutenção contínua. Outras equipes podem estar dispostas a contribuir com funcionalidades, mas é menos provável que estejam dispostas 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 contribuído ou até mesmo revisar solicitações pull. O conceito de um provedor de plataforma de desenvolvedor alivia essa tensão, permitindo que o código escrito de forma independente se conecte à funcionalidade principal dentro de sua base de autoatendimento do desenvolvedor. Embora você deva gerenciar cuidadosamente quais provedores você usa, revisar qualquer código de 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

Entities

O conceito de entidade é algo que um desenvolvedor ou outro sistema em sua plataforma interna de desenvolvedor precisa acompanhar, atualizar, apresentar ou agir. As entidades podem ter relações entre si que, quando tomadas em conjunto, compõem um gráfico que fornece informações críticas sobre partes da sua plataforma de desenvolvedor interna. Os provedores de plataforma de desenvolvedor podem, então, produzir entidades para habilitar os recursos principais, incluindo:

• Surgimento de 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.
• Exibição de informações sobre responsáveis / proprietários para descoberta e colaboração
• Expondo mais dados para uso em experiências de utilizador

Encapsular essa funcionalidade em uma interface de provedor de plataforma de desenvolvedor bem definida simplifica a integração e os testes, permite a implantação independente e permite que desenvolvedores fora da equipe interna principal da plataforma de desenvolvedor contribuam e gerenciem provedores. Isso é importante em organizações grandes ou divisionais, onde 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 para se 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 considerar incluem:

• Identificador exclusivo
• Nome
• Fornecedor de origem
• Associações facultativas para:
  • Utilizador proprietário
  • Equipa 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 no nível da equipe). Incorporar o RBAC desde o início é fundamental para a segurança e para o crescimento de sua plataforma interna de desenvolvedores ao longo do tempo. Dado que o desenvolvimento é um desporto de equipa, descobrir quem contactar sobre uma entidade rapidamente se tornará crítico para a reutilização, suporte e sourcing interno.

Entidades comuns e específicas do fornecedor

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

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

Estes geralmente devem estar em um nível alto, como você colocaria no contexto do modelo C4 ou na maioria dos diagramas de componentes de alto nível. Por exemplo, para um ambiente, você não precisa incluir os detalhes da topografia da infraestrutura interna; você só precisa de informações suficientes para listar e associar diferentes ambientes conceituais de vários provedores na mesma UX. A entidade pode apontar para camadas inferiores de detalhe fora do âmbito do sistema, em vez de tentar processar todos os dados. Eles fornecem pontos de partida para a descoberta que são fundamentais para habilitar a agregação de dados ao longo do tempo.

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

Modelos

O conceito de um modelo neste contexto difere da ideia de entidades na medida em que se destinam a conduzir uma ação. Cenários de exemplo incluem provisionamento de infraestrutura, criação de um repositório e outros processos de longa execução. Esses modelos também devem estar disponíveis por meio de provedores de plataforma de desenvolvedor extensíveis e devem suportar as mesmas propriedades comuns que entidades, incluindo associações de entidades.

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

Exemplos de modelos incluem:

• Modelos de infraestrutura como código (IaC)
• Modelos de aplicativo (começar à direita) ou repositórios de modelos
• Criar modelos de pipeline / fluxo de trabalho
• Modelos de workflow / pipeline de implantação
• Scripts parametrizados
• Fluxos parametrizados Power Automate (por exemplo, uma solicitação HTTP acionou o fluxo de nuvem)
• Modelos de e-mail

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

Cada modelo pode ter uma representação diferente que é exclusiva para o provedor. Eles podem variar de templates Terraform ou ARM a Helm Charts, fluxos de trabalho parametrizados de GitHub Actions ou Azure Pipelines, scripts simples ou formatos personalizados.

Os detalhes reais do modelo subjacente não precisam necessariamente ser armazenados centralmente. Podem existir em diferentes repositórios, registos ou catálogos. Por exemplo, você pode usar repositórios de modelos do GitHub para seus modelos de aplicativo, enquanto seus modelos 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 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. Mas, os modelos em si podem ser alojados no local mais natural para seus casos de uso.

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

Gráfico da plataforma do desenvolvedor

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

O gráfico é poderoso quando usado com entidades comuns que vários provedores poderiam contribuir. Por exemplo, uma lista de APIs pode vir de um produto como o Centro de APIs do Azure, mas você também pode querer alimentar automaticamente implantações e ambientes de seus sistemas de implantação contínua. Com o tempo, você pode alternar entre diferentes sistemas de implantação ou até mesmo dar suporte a mais de um sistema de implantação. Contanto que cada sistema de implantação tenha um provedor de plataforma de desenvolvedor, você ainda poderá fazer a associação.

Cada uma das suas experiências de usuário que se acumulam a partir deste gráfico pode então tirar proveito de uma API comum para impulsionar a descoberta, pesquisa, governança e muito mais. Um orquestrador de plataforma de desenvolvedor pode então aproveitar esse mesmo gráfico 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 plataformas 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, mecanismo de fluxo de trabalho ou outro orquestrador para fazê-lo. É uma das peças críticas que deverá garantir ter integradas na 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 Ações do GitHub, Pipelines do Azure ou outro mecanismo de fluxo de trabalho como seu orquestrador. Este é um lugar razoável para começar, mas você pode querer ter um pouco de abstração para permitir que diferentes tipos de modelos usem diferentes mecanismos subjacentes. Isso pode ser útil por alguns motivos:

• Primeiro, você provavelmente vai querer ser capaz de escolher diferentes mecanismos de fluxo de trabalho e execução de tarefas ao longo do tempo sem ter que cortar o flash. 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 low-code como o Power Automate geralmente funcionam bem para essas funções.
• Outras ações podem ser tratadas por meio de solicitações HTTP simples, nas quais inicializar algo tão capaz como o GitHub Actions ou o Azure Pipelines não é necessário nem econômico para escalar.

Felizmente, expandir a ideia de um fornecedor de plataforma para desenvolvedores para cobrir as etapas de automação de acionamento e monitorização pode fornecer essa abstração necessária. Considere a seguinte ilustração:

Eis o conceito geral:

• Os modelos podem, opcionalmente, especificar um conjunto de entradas que o usuário pode inserir. Quando um desenvolvedor aciona uma ação específica, ele escolhe um modelo (mesmo que não seja descrito dessa forma) e insere todas as entradas.
• Uma referência às entradas relacionadas ao modelo torna-se uma solicitação na API da plataforma do desenvolvedor.
• 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 componente de roteamento e manipulação de solicitações direciona o modelo contido na solicitação para o fornecedor da plataforma de desenvolvedor onde o modelo se originou.
• Em seguida, o provedor da plataforma do desenvolvedor executa as etapas apropriadas para sua implementação.
• (Opcional) O provedor da plataforma do desenvolvedor atualiza o status da solicitação à medida que executa a ação.
• Depois que a solicitação for atendida, o provedor da plataforma do desenvolvedor poderá retornar um conjunto de entidades para adicionar ou atualizar no gráfico da plataforma do desenvolvedor. Estas podem ser entidades específicas do fornecedor ou comuns.

Opcionalmente, para oferecer 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ê quer algo que faça a ponte entre o que você montou como parte dos sistemas de engenharia de software da Apply. Um fluxo de trabalho geral ou mecanismo de execução de tarefas para investir é um sistema CI/CD.

Um exemplo usando Ações do GitHub ou Pipelines do Azure

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

Para as Ações do GitHub, a chave para isto funcionar é que um fornecedor de plataforma de desenvolvimento pode conectar-se à instância especificada do GitHub e usar a API REST de Ações para disparar um evento de ativação do fluxo de trabalho para desencadear uma execução do fluxo de trabalho. Cada fluxo de trabalho pode suportar um conjunto de entradas adicionando uma configuração de workflow_dispatch ao arquivo YAML do 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 de aplicativos. O conceito seria aproveitar esse fato para fazer algo assim:

• 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 da plataforma do desenvolvedor está configurado para usar. Esse mesmo repositório pode incluir scripts e trechos de IaC que os fluxos de trabalho/pipelines usam.
• Para permitir que esses fluxos de trabalho/pipelines interajam com o sistema a jusante apropriado, a equipa de operações ou outros membros da equipa de engenharia da plataforma podem adicionar os segredos necessários no repositório central. Consulte Ações do GitHub e 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.
• Esses fluxos de trabalho/pipelines podem seguir um modelo no qual publicam quaisquer entidades resultantes como um artefato de compilação/implantação (documentos do GitHub, documentos do Azure DevOps).
• Durante uma execução, o fornecedor da plataforma de desenvolvimento pode observar o estado do fluxo de trabalho/pipeline e atualizar o estado do ciclo de vida no orquestrador até que seja concluído. Por exemplo, você pode usar ganchos da Web com Ações do GitHub e ganchos de serviço com o Azure Pipelines para rastrear atualizações.
• Depois de concluído, o provedor pode consumir o artefato publicado para inclusão no gráfico da plataforma do desenvolvedor, conforme necessário.

Finalmente, você pode configurar esse provedor de plataforma de desenvolvedor para gerar um conjunto de modelos no gráfico da plataforma do desenvolvedor que fazem referência ao repositório apropriado e ao fluxo de trabalho/pipeline, juntamente com entradas para uma determinada tarefa.

A melhor coisa sobre o uso de um sistema de CI/CD é que eles geralmente são configurados para suportar a execução de CLIs arbitrárias, para que você não precise de uma integração exclusiva de primeira classe para tudo o que faz. Você pode adicioná-los ao longo do tempo, conforme necessário.

Muito do que é descrito neste exemplo aplica-se à forma como outros tipos de fornecedores poderiam funcionar. Também é importante observar que o uso de Ações do GitHub ou Pipelines do Azure neste 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 poderiam processar modelos.

Embora 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.

Utilizadores e equipas

A engenharia de plataforma é inerentemente um assunto de vários sistemas, por isso é importante planejar como uma fundação de autosserviço deve lidar com os problemas mais desafiadores com a integração desses sistemas juntos. Aqui está uma estratégia para enfrentar desafios comuns com identidade, usuários e equipes.

Estabeleça 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 plataformas, definimos uma equipa como um conjunto de pessoas em diferentes funções que trabalham em conjunto. Para a agregação de dados, a ideia de uma equipe de várias funções é fundamental para potencializar a descoberta e o acúmulo de informações em locais como painéis de relatórios. Por outro lado, um grupo é um conceito geral de provedor de identidade para um conjunto de usuários e é projetado com a ideia de adicionar várias pessoas a uma função específica, e não o 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 fonte dos dados da sua equipe pode vir de alguns lugares diferentes. Por exemplo, se estiver a usar o padrão de equipas como código (TAC), um fornecedor de plataforma de desenvolvimento pode monitorizar as alterações de ficheiros num repositório e guardá-las em cache num perfil de utilizador e numa base de dados de metadados da equipa. Ou você pode integrar diretamente com algo como um Projeto do Centro de Desenvolvimento do Azure que já tem essas construções RBAC principais disponíveis.

Estabelecer um modelo de integração com sistemas downstream ao nível da equipa ou do utilizador

Enquanto algumas ferramentas/serviços de desenvolvimento e operações integram nativamente e usam conceitos de provedor de identidade diretamente, muitos abstraem isso em sua própria representação de um grupo ou usuário (mesmo com SSO). Além de permitir 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 (por exemplo, o ID do objeto no Entra ID não é usado 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 IDs diferentes.

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

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

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

Se preferir usar uma fonte de dados diferente de arquivos no repositório das suas equipas, esse mesmo conceito geral pode ser aplicado usando o orquestrador da plataforma do desenvolvedor para atingir o mesmo objetivo. Sob esse modelo, um fornecedor de plataforma de desenvolvedor para a origem dos dados da equipa pode acionar um evento de atualização de equipa que todos os outros fornecedores recebem e agem conforme apropriado.

Enfrente os desafios do ID do usuário

Outro desafio relacionado ao acesso e agregação de dados são as diferenças de ID do usuário. Como no caso da equipe, se você usar uma integração sistema-a-sistema para consultar dados sobre um usuário, não poderá presumir que a ID nativa dos provedores de identidade (por exemplo, ID de objeto para ID do Entra) suporta uma determinada API. Aqui, novamente, armazenar um mapeamento para um ID de usuário que acessa dados por meio da API da plataforma do desenvolvedor pode ajudar. Por exemplo, considere o GitHub:

Para cada sistema, se você puder fazer uma pesquisa de um 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 pode gerar esse mapeamento imediatamente. 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 utilizador

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 do usuário que funcionaria, a API da plataforma do desenvolvedor pode ser configurada para gerenciar vários tokens de usuário. Por exemplo:

• A API da plataforma de desenvolvedor poderia suportar um cache de tokens de usuário específicos do provedor para uso com sistemas downstream.
• Quaisquer interações com um determinado provedor acionadas pela API incluirão o 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 acionaria um fluxo OAuth para obter um.
• Para começar, a API da plataforma de desenvolvimento devolveria um URI de autenticação para um fluxo OAuth, incluindo a URI de redirecionamento fornecida ao provedor. A URI passada incluiria um código nonce / de uso único.
• Em seguida, a API retorna uma resposta não autenticada com o URI.
• Qualquer UX pode usar esse URI para direcionar o fluxo de autenticação apropriado em um navegador.
• Uma vez que o redirecionamento acontece, a plataforma do desenvolvedor receberá o token de usuário necessário e o armazenará em cache para referência futura, juntamente com o ID do usuário.
• O cliente poderia então tentar novamente a chamada de API, que seria bem-sucedida.

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

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

Até este ponto, temos falado sobre o aspeto de automação do espaço problemático. Isso por si só pode ajudar muito, 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 estão relacionados com a automação, os provedores de plataformas de desenvolvimento podem emitir qualquer tipo de entidade necessária. No entanto, você geralmente não quer trazer todos os dados detalhados de toda a sua plataforma de desenvolvedor interna para o gráfico da plataforma de desenvolvedor. Painéis em soluções de observabilidade como Grafana, Prometheus, DataDog ou inteligência de código em produtos como SonarQube, e recursos nativos em suítes de DevOps como GitHub e Azure DevOps, são todos capazes. Em vez disso, a melhor abordagem é, muitas vezes, criar ligações profundas com 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 dados agregados e resumidos entre ferramentas ou precisa gerar métricas personalizadas, as soluções de relatórios Power BI ou Microsoft Fabric podem ser sua próxima porta de chamada. Para mesclar dados da 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 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ê constrói

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

Dito isso, o modelo aqui permite que você use dados agregados no gráfico da plataforma do desenvolvedor para criar experiências de usuário personalizadas. 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 desenvolvimento defina o escopo dos resultados (juntamente com o uso de indexação e cache).

No entanto, mesmo quando você precisa criar UX personalizada em vez de um link profundo, extrair todos os dados para o gráfico da plataforma do desenvolvedor normalmente ainda não é a melhor abordagem. Por exemplo, considere uma situação em que você pode querer exibir logs em sua experiência do usuário que já tem uma casa bem definida e gerenciada. Use as informações nas entidades relacionadas para ajudar sua UX 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 armazenados ou tokens de autenticação de usuário, se necessário.

Eis alguns exemplos de experiências comuns a considerar:

Experiências do utilizador

Diferentes funções na sua organização têm ferramentas ou serviços que representam um centro de gravidade para o seu trabalho diário. A atração desses sistemas pode dificultar que novas experiências de usuário fora desses centros de gravidade ganhem tração. Em um mundo perfeito, desenvolvedores, operações e outras funções podem continuar a trabalhar em um ambiente que faça 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 sua jornada de engenharia de plataforma é uma boa ideia. Isso também pode fornecer uma oportunidade para começar simples, provar valor e crescer para interfaces mais complexas à medida que a necessidade surge.

Integre os componentes que possui

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 melhorar e ampliar o que você tem antes de começar a construir novas experiências do zero. (Pergunte a si mesmo, as pessoas vão reagir melhor a outra nova experiência de usuário ou uma versão melhorada de algo que eles têm agora?)

Algumas das ferramentas, utilitários ou aplicativos Web que você deseja continuar usando serão personalizados, e esses são bons candidatos 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á muitos benefícios ao 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, poderá conseguir alargar as seguintes superfícies que já está a utilizar:

• Editores e IDEs
• Seu pacote de DevOps
• As CLIs também são cada vez mais extensíveis
• Ambientes low/no-code como Power Pages

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

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

Se você está procurando uma experiência baseada na Web para desenvolvedores, lembre-se de que uma tendência recente são as versões baseadas na Web de editores e IDEs. Muitos, como aqueles que usam o VS Code, têm suporte a extensão. Com o VS Code, tudo o que você cria para essas experiências na Web é traduzido localmente para um benefício duplo.

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

Mesmo que seus 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. O uso do vscode.dev pode fornecer uma base baseada na Web conveniente e familiar para experiências de desenvolvedores, além da própria ferramenta.

Estes 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 muitas vezes é negligenciada é a implementação de uma interface ChatOps. Dado o aumento de interfaces baseadas em bate-papo 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 acionar fluxos de trabalho de automação, verificar o status e muito mais. Dado 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 integração com outra interface do usuário que os desenvolvedores e funções de operações relacionadas usam todos os dias. Além disso, todos estes produtos têm um modelo de extensibilidade.

Investindo 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 e não como um ponto de partida. Se você ainda não tem uma equipe de desenvolvimento trabalhando com você, começar esse esforço é o momento de fazê-lo. Cada organização é diferente, por isso não há uma resposta única para o que deve ser neste tipo de experiência. Como resultado, não há uma resposta padrão para um produto pré-embalado que você possa iniciar e usar tal como está para algo assim hoje.

Para opções personalizadas autoalojadas, as estruturas gerais de portais web não são novas, e as suas equipas de desenvolvimento podem já estar a utilizar uma que você possa aproveitar. Se estás a tentar apresentar algo aos teus utilizadores para recolher feedback antecipado, podes até começar com algo tão simples como o Power Pages de baixo código para te conectares à API comum da plataforma de programadores.

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 inicialmente criado para atender às necessidades do Spotify. Ele inclui uma CLI para ajudar a inicializar sua árvore de código-fonte, da mesma forma que create-react-app faz para React.js.

Como um kit de ferramentas de portal, ele requer trabalho para configurar e a personalização requer conhecimento de TypeScript, Node.js e React. No entanto, o melhor é que, como um kit de ferramentas, você pode mudar quase tudo. Ele também tem o seu próprio catálogo de software e mecanismo de modelos, mas o seu uso não é obrigatório, e é uma forma bem definida de trazer novo código, chamado plugins.

Conteúdo relacionado

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