Criar uma base self-service para programadores

Assim que tiver uma boa compreensão do seu destino para os seus sistemas de engenharia, pode começar a criar experiências personalizadas para programadores mais sofisticadas. Nesta secção, descrevemos uma arquitetura conceptual para criar ou avaliar produtos que criam uma base flexível para os criar. Referimo-nos a estes conceitos, padrões e componentes, coletivamente, como uma base self-service do programador.

Embora possa não precisar de tudo o que está descrito aqui na sua organização hoje, deve ter estes conceitos em mente se criar algo personalizado ou avaliar produtos relacionados. No seu mundo, este modelo pode ser composto por uma combinação de produtos caseiros, fora da prateleira e open source. Produtos ou toolkits de portal open source, como Backstage.io podem utilizar termos diferentes para alguns elementos do modelo descritos nesta secção, mas o modelo ainda pode ajudá-lo a orientá-lo.

Goals e considerações

O principal objetivo dos seus esforços nesta área deve ser permitir a gestão personalizada com proteções através de execução e aprovisionamento de tarefas controlados e regidos, juntamente com visibilidade centralizada. As áreas que são muitas vezes as mais valiosas para se concentrar são aquelas que são aborrecidas ou são coisas que o programador não pode fazer por si mesmo devido a complexidade ou permissões. Esta última peça é importante para permitir que siga o princípio do menor privilégio sem forçar os programadores através de um processo de service desk manual.

Embora possa optar por expandir o seu conjunto de aplicações de DevOps para satisfazer estas necessidades, provavelmente terá de suportar várias plataformas de aplicações ao longo do tempo e as ferramentas e processos específicos que os suportam também terão de ser alterados. O problema principal é que as normas são um destino em movimento. Como um profissional de engenharia de plataforma afirmou:

As dificuldades envolvem a uniformização... e a lidar com o "abandonware"... Muitas vezes, a uniformização não é conseguida devido a uma potencial interrupção dos processos automatizados e à tarefa demorada de identificar as alterações necessárias. - Martin, Engenheiro de DevOps, Grande Empresa de Logística

Como realça esta citação, mudar rapidamente para um padrão novo ou atualizado normalmente não é viável e abandonar os processos existentes cria riscos. A sua organização pode já estar a utilizar vários conjuntos de aplicações de DevOps ou diferentes combinações de ferramentas individuais e serviços de programador por cenário. Mesmo com uma equipa central e uma solução padrão, à medida que as suas necessidades de gestão personalizada aumentam, a variabilidade é inevitável. Por isso, vai querer ativar a experimentação controlada em que as equipas designadas podem experimentar novas tecnologias, estratégias de implementação, entre outras, seguidas de adoção deliberada e implementação incremental.

Geralmente, as experiências self-service enquadram-se em duas categorias primárias:

• Automatização
• Agregação de dados

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

A automatização é fundamental e será amada por todos. [Dados] a agregação é secundária. – Peter, líder de engenharia de plataformas, multinacional tecnológica

Por este motivo, é provável que o percurso de engenharia da plataforma que cartografou tenha identificado alguns problemas que poderiam ser resolvidos pela automatização. Para além da redução da carga cognitiva e do trabalho do programador, a automatização também pode ajudar a garantir que as aplicações estão ligadas às melhores ferramentas e serviços para operações, segurança e outras funções para fazer o seu trabalho.

No entanto, se estiver a trabalhar com mais do que um sistema para impulsionar a automatização, algum nível de agregação de dados é útil para ajudar a controlar os pedidos automatizados e os resultados associados. Muitas vezes, pode começar por ligar a sistemas externos para satisfazer outras necessidades ou para obter detalhes. A agregação e visibilidade de dados também são importantes para a auditoria, governação e redução de resíduos (por exemplo: ambientes não utilizados).

Automatizar aspetos como o aprovisionamento de infraestrutura pode ser feito através de integrações do sistema, mas também pode acionar e facilitar um processo de fluxo de trabalho manual que parece automatizado para o programador. Isto é útil nas fases iniciais da sua plataforma, para novos produtos que está a trazer para o seu ecossistema ou em áreas que não tem ou não consegue automatizar com um sistema (por exemplo, atribuição de licenças de software). Com a estrutura certa, pode começar com um processo manual facilitado por algo como o Power Automate que muda para um fluxo totalmente automatizado ao longo do tempo. Assim, crie uma automatização desde o início.

Tendo em conta uma mentalidade de produto e a ideia de uma plataforma mais fina e viável (TVP) (um MVP para a sua plataforma), deve começar por reutilizar investimentos existentes, como os seus sistemas de engenharia ou um portal interno, criar CLIs, páginas Web básicas ou até mesmo dashboards do Power Pages, Power BI ou Microsoft Fabric e expandir à medida que a necessidade surge. Tendo isso em mente, ter uma API consistente que o UX utiliza pode ajudá-lo a suportar várias interfaces ao longo do tempo à medida que as suas necessidades e preferências mudam.

Descrição geral dos conceitos

Considere a seguinte ilustração:

Como mostra a ilustração, os seguintes componentes constituem o núcleo do conceito de base self-service do programador:

Componente	Descrição
API da plataforma de programadores	Este é o seu único ponto de contacto para experiências de utilizador. É efetivamente o contrato do sistema com outros sistemas.
Gráfico da plataforma de programadores	Um gráfico de dados gerido e seguro que lhe permite detetar, associar e utilizar diferentes tipos de entidades e modelos. Uma entidade é um objeto que permite a agregação de dados a partir de várias origens, enquanto os modelos impulsionam as entradas de utilizador que permitem a automatização.
Orquestrador da plataforma de programadores	Uma capacidade que encaminha e monitoriza pedidos baseados em modelos para realizar ações num sistema ou através de um processo manual. Estes pedidos são encaminhados para um conjunto de fornecedores de plataformas de programadores que podem ser integrados em qualquer número de sistemas de fluxo de trabalho ou outros serviços diferentes.
Fornecedores de plataformas de programadores	Um conjunto de componentes que encapsulam a lógica necessária para integrar com sistemas a jusante para suportar operações CRUD em entidades e/ou cumprimento de pedidos de ação baseados em modelos. Cada fornecedor pode suportar o seu próprio tipo específico de modelos e emitir tipos de entidades exclusivos ou comuns.
Perfis de utilizador e metadados de equipa	Uma capacidade para manter informações sobre um conjunto de indivíduos ligados a uma equipa conceptual para agrupar e aceder à API da plataforma de programadores. O utilizador está intimamente associado a uma conta de fornecedor de identidade (por exemplo, Microsoft Entra ID iniciar sessão), mas tanto ele como uma equipa podem associar-se a qualquer número de representações do sistema a jusante relacionadas. Uma implementação deste arquivo de informações é reutilizar o grafo da plataforma de programador. A base self-service do programador pode estabelecer um tipo de entidade comum para um utilizador e uma equipa e manter essas informações no gráfico. No entanto, vamos manter esta loja separada por uma questão de clareza aqui.

Estes componentes fundamentais permitem-lhe utilizar e trocar blocos modulares diferentes ao longo do tempo. Vamos analisar cada um destes detalhes mais detalhadamente nas secções subsequentes.

Tenho de criar tudo isto para começar?

Não, não. Em primeiro lugar, este é um modelo conceptual para ajudá-lo a pensar através do que uma fundação como esta deve ser capaz de fazer assim que estiver feito. Em segundo lugar, as especificações de implementação são menos importantes aqui, dado que a API da plataforma de programadores se torna a sua interface chave. A implementação inicial pode começar a utilizar interfaces e classes no seu código para as diferentes camadas descritas ou misturadas noutros produtos. Também pode omitir aspetos porque o desenvolvimento do cliente indica que é simplesmente uma prioridade mais baixa. Comece com o que tem e cresça.

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

API da plataforma de programadores

Deve definir uma API de plataforma de programador para atuar como contrato do seu sistema. A API é utilizada por diferentes interfaces de utilizador para ativar o acesso a dados ou o aprovisionamento de unidades e outras ações.

Esta API também deve funcionar como uma importante camada de autenticação e segurança ao limitar o acesso a APIs subjacentes não processadas noutros sistemas a dados e operações mais específicos e controlados. A API fornece acesso à sua própria representação de um perfil de utilizador, à função de alto nível de um utilizador na plataforma (membro da equipa, administrador, etc.) e aos identificadores de sistema do fornecedor de identidade principal. Para obter mais informações, consulte Utilizadores e equipas.

Fornecedores de plataformas de programadores

Dada a amplitude de uma plataforma de programador interna, recomendamos que crie ou procure sistemas que sigam um modelo de fornecedor extensível para introduzir funcionalidades na API. A ideia é que a funcionalidade-chave, como a automatização e a agregação de dados, seja fornecida através da interação com componentes plug-able com interfaces bem definidas. Este acoplamento solto ajuda-o a ligar o que precisa incrementalmente e melhora a manutenção, uma vez que pode testar funcionalidades independentes do resto da base.

É também uma forma importante de permitir uma mentalidade de origem interna dimensionável para a sua plataforma. Normalmente, os esforços internos de fornecimento em torno da engenharia da plataforma não conseguem ganhar tracção devido a desafios com a manutenção contínua. Outras equipas podem estar dispostas a contribuir com funcionalidades, mas são menos propensos a manter e testar algo dentro do núcleo da sua plataforma. Por outro lado, qualquer equipa centralizada tem capacidade limitada para manter o código contribuído ou até mesmo rever pedidos Pull. O conceito de um fornecedor de plataformas de programadores alivia esta tensão ao permitir que o código escrito independentemente "ligue" à funcionalidade principal na base self-service do programador. Embora deva gerir cuidadosamente os fornecedores que utiliza, rever qualquer código do fornecedor e limitar a área de superfície a que um determinado fornecedor pode aceder na sua plataforma de programador, uma abordagem plug-able pode ajudá-lo a fazer mais ao dimensionar o esforço numa parte mais ampla da organização.

Principais conceitos do fornecedor de plataformas para programadores

Entidades

O conceito de uma entidade é algo em que um programador ou outro sistema na sua plataforma de programador interno precisa de controlar, atualizar, apresentar ou agir. As entidades podem ter relações entre si que, quando juntas, constituem um gráfico que fornece informações críticas sobre partes da sua plataforma de programador interna. Os fornecedores de plataformas de programadores podem, em seguida, produzir entidades para ativar as capacidades principais, incluindo:

• Recursos/ambientes aprovisionados externamente ou APIs disponíveis para deteção e utilização
• Expor relações para análise de dependências, análise de impacto, deteção, etc.
• Informações de manutenção/propriedade sobre a deteção e colaboração
• Apresentar mais dados para utilização em experiências de utilizador

Encapsular esta funcionalidade numa interface de fornecedor de plataforma de programador bem definida simplifica a integração e os testes, permite a implementação independente e permite que os programadores fora da equipa principal da plataforma interna de programadores contribuam e gerem fornecedores. Isto é importante em organizações grandes ou divisionais onde nem todas as ferramentas, serviços ou plataformas são geridos centralmente, mas a organização mais ampla ainda quer partilhar capacidades. Por isso, mesmo que não sigas este 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 faça. Algumas propriedades a considerar incluem:

• Identificador exclusivo
• Nome
• Fornecedor de origem
• Associações opcionais para:
  • Utilizador proprietário
  • Equipa proprietária
  • Outras entidades

As propriedades do utilizador e da equipa são importantes por três razões: controlo de acesso baseado em funções (RBAC), deteção e agregação de dados (como resumos ao nível da equipa). A criação no RBAC desde o início é fundamental para a segurança e o crescimento da plataforma de programadores internos ao longo do tempo. Dado que o desenvolvimento é um desporto de equipa, descobrir com quem falar sobre uma entidade rapidamente se tornará fundamental para reutilização, suporte e innersourcing.

Entidades comuns e específicas do fornecedor

Também deve conseguir estabelecer um conjunto de entidades normalizadas comuns de alto nível que vários fornecedores podem produzir. Por exemplo:

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

Geralmente, estes devem estar num nível elevado, como faria no contexto do modelo C4 ou nos diagramas de componentes de nível mais elevado. Por exemplo, para um ambiente, não precisa de incluir os detalhes da topografia da infraestrutura interna: só precisa de informações suficientes para listar e associar diferentes ambientes conceptuais de vários fornecedores no mesmo UX. A entidade pode apontar para níveis mais baixos de detalhe fora do sistema em vez de tentar consumir tudo. Estes fornecem pontos de partida para a deteção que são centrais para ativar a agregação de dados ao longo do tempo.

Outros serão específicos para um determinado caso de utilização ou fornecedor, pelo que 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 impulsionar uma ação. Os cenários de exemplo incluem o aprovisionamento de infraestrutura, a criação de um repositório e outros processos de execução prolongada. Estes modelos também devem estar disponíveis através de fornecedores de plataformas de programadores extensíveis e devem suportar as mesmas propriedades comuns que as entidades , incluindo associações de entidades.

No entanto, também podem definir as entradas necessárias, quer sejam especificadas pelo sistema ou pelo utilizador, que são necessárias para efetuar a ação. Estes podem ir de qualquer coisa como atribuir nomes ao recurso a adições opcionais.

Exemplos de modelos incluem:

• Modelos de infraestrutura como código (IaC)
• Modelos de aplicação (Iniciar à Direita) ou repositórios de modelos
• Criar modelos de pipeline/fluxo de trabalho
• Pipeline de implementação/modelos de fluxo de trabalho
• Scripts parametrizados
• Fluxos do Power Automate parametrizados (exemplo: um pedido HTTP acionado na cloud)
• Email modelos

Tal como as entidades, os modelos podem incluir propriedades específicas do fornecedor.

Cada modelo pode ter uma representação diferente que é exclusiva do fornecedor. Estes podem ir desde modelos do Terraform ou arm até Gráficos Helm, fluxos de trabalho GitHub Actions parametrizados ou Pipelines do Azure, scripts simples ou formatos personalizados.

Os detalhes reais do modelo subjacente não precisam necessariamente de ser armazenados centralmente. Podem existir em repositórios, registos ou catálogos diferentes. Por exemplo, pode utilizar repositórios de modelos do GitHub para os seus modelos de aplicação, enquanto os seus modelos IaC podem existir num repositório de catálogo restrito ao qual os programadores só podem aceder indiretamente através de algo como Ambientes de Implementação do Azure. Outros modelos IaC podem ser armazenados num Registo de Artefactos OCI, como gráficos Helm. Noutros casos, o modelo pode ser uma referência a um ponto final HTTP parametrizado. Um fornecedor de plataforma de programador deve fornecer informações suficientes sobre cada tipo de modelo para que possam ser referenciados e quaisquer opções expostas para utilização em experiências de utilizador. Contudo, os próprios modelos podem ser alojados na localização mais natural para os seus casos de utilização.

Os engenheiros ou especialistas da plataforma numa área específica escrevem estes modelos e, em seguida, partilham-nos com equipas de desenvolvimento para reutilização. Centralizar a utilização destes modelos através de um sistema permite o self-service do programador e cria proteções que ajudam a impor a conformidade com as normas ou políticas organizacionais. Mais informações sobre isto quando abordamos o orquestrador da plataforma de programadores daqui a pouco.

O gráfico da plataforma de programadores

Pode considerar um gráfico de plataforma de programador como algo que lhe permite associar entidades e modelos de vários fornecedores a um gráfico pesquisável. No entanto, os dados reais das entidades não precisam necessariamente de ser mantidos diretamente numa base de dados específica do gráfico. Em vez disso, as interações com fornecedores poderiam ser colocadas em cache juntamente com os metadados necessários para que tudo se encaixasse.

O gráfico é poderoso quando utilizado com entidades comuns que podem contribuir com vários fornecedores. Por exemplo, uma lista de APIs pode ser proveniente de um produto como o Centro de API do Azure, mas também poderá querer alimentar-se automaticamente em implementações e ambientes a partir dos seus sistemas de implementação contínua. Ao longo do tempo, pode alternar entre sistemas de implementação diferentes ou até mesmo suportar mais do que um sistema de implementação. Desde que cada sistema de implementação tenha um fornecedor de plataforma de programador, ainda deverá conseguir criar a associação.

Cada uma das suas experiências de utilizador que se acumulam a partir deste gráfico pode, em seguida, tirar partido de uma API comum para deteção de energia, pesquisa, governação e muito mais. Um orquestrador de plataforma de programadores pode, em seguida, tirar partido deste mesmo grafo para que quaisquer ações executadas por um fornecedor de plataforma de programador contribuam automaticamente com entidades disponíveis para a mesma API.

Orquestrador da plataforma de programadores

Um orquestrador de plataforma de programadores permite que programadores ou sistemas criem pedidos para realizar uma ação com um modelo. Não executa estas ações em si, mas coordena com um motor de tarefas, um motor de fluxo de trabalho ou outro orquestrador para o fazer. É uma das peças críticas que vai querer ter a certeza de que faz parte da sua base self-service. Permite que os programadores criem pedidos com um modelo ou executem uma ação sem permissão direta. Além disso, ao contrário do conceito de CI ou CD, estas ações não têm de estar relacionadas com o código fonte da aplicação.

Conforme descrito em Aplicar sistemas de engenharia de software, pode utilizar GitHub Actions, pipelines do Azure ou outro motor de fluxo de trabalho como orquestrador. Este é um local razoável para começar, mas poderá querer ter um pouco de abstração no local para permitir que diferentes tipos de modelos utilizem diferentes motores subjacentes. Isto pode ser útil por alguns motivos:

• Primeiro, é provável que queira ser capaz de escolher diferentes fluxos de trabalho e motores de execução de tarefas ao longo do tempo sem ter de fazer um flash cut. Ao permitir mais do que um motor, pode migrar ao longo do tempo ou simplesmente a utilização do novo motor para novas ações sem afetar as mais antigas.
• Alguns processos que pretende ajudar a orquestrar poderão exigir passos manuais inicialmente, mesmo que planeie automatizá-los totalmente mais tarde.
• Outras ações podem visar funções fora da equipa de programador, como contas a pagar ou um administrador de licenças. Os motores de baixo código, como o Power Automate, funcionam frequentemente bem para estas funções.
• Outras ações podem ser processadas através de pedidos HTTP simples em que gerar algo tão capaz como GitHub Actions ou pipelines do Azure não é necessário ou económico para dimensionar.

Felizmente, expandir a ideia de um fornecedor de plataforma de programador para abranger os passos de automatização de acionamento e controlo pode fornecer esta abstração necessária. Considere a seguinte ilustração:

Eis o conceito geral:

1. Opcionalmente, os modelos podem especificar um conjunto de entradas que o utilizador pode introduzir. Quando um programador aciona uma determinada ação, escolhe um modelo (mesmo que não seja descrito dessa forma) e introduza quaisquer entradas.
2. Uma referência às entradas relacionadas com o modelo torna-se um pedido na API da plataforma de programadores.
3. Assim que um pedido é submetido, um componente de encaminhamento e processamento de pedidos no orquestrador começa a controlar o ciclo de vida do pedido. O modelo de encaminhamento de pedidos e processamento de rotas de componentes no pedido ao fornecedor da plataforma de programadores de origem do modelo.
4. Em seguida, o fornecedor da plataforma de programadores executaria os passos adequados para a sua implementação.
5. [Opcional] O fornecedor da plataforma de programadores atualiza o estado do pedido à medida que executa a ação.
6. Assim que o pedido for cumprido, o fornecedor da plataforma de programadores pode devolver um conjunto de entidades para adicionar/atualizar no gráfico da plataforma de programadores. Podem ser entidades específicas ou comuns do fornecedor.

Opcionalmente, para suportar interações mais avançadas, pode permitir que estes fornecedores de plataformas de programadores chamem diretamente a API da plataforma de programadores para obter mais entidades como entradas ou até mesmo pedir outra ação relacionada.

Embora a solução específica ou um produto que esteja a avaliar possa variar, isto deve dar-lhe uma ideia das qualidades a procurar.

Com isto em mente, vai querer ter um fornecedor de plataforma de programador que utilize uma tarefa geral ou um motor de fluxo de trabalho. Mais especificamente, vai querer fazer uma ponte entre o que reuniu como parte dos sistemas de engenharia de software Apply. Um fluxo de trabalho geral ou um motor de execução de tarefas no qual provavelmente irá investir é o seu sistema CI/CD.

Um exemplo com GitHub Actions ou pipelines do Azure

Vejamos resumidamente como funcionaria um GitHub Actions ou o Azure Pipelines como fornecedor de plataformas de programadores.

Para GitHub Actions, a chave para fazer este trabalho é que um fornecedor de plataforma de programador pode ligar-se à instância do GitHub especificada e utilizar a API REST de Ações para acionar um evento de distribuição de fluxo de trabalho para acionar uma execução de fluxo de trabalho. Cada fluxo de trabalho pode suportar um conjunto de entradas ao adicionar uma configuração de workflow_dispatch ao ficheiro YAML do fluxo de trabalho. Os acionadores do Azure DevOps são semelhantes e também pode utilizar a API de Pipeline do Azure DevOps para execuções. É provável que veja as mesmas capacidades noutros produtos.

Estes fluxos de trabalho/pipelines não precisam de estar nos repositórios de código fonte da aplicação. O conceito seria tirar partido deste facto para fazer algo assim:

1. Os engenheiros da plataforma ou os membros da equipa do DevOps podem manter os fluxos de trabalho/pipelines num ou mais repositórios centrais aos quais os próprios programadores não têm acesso, mas o fornecedor da plataforma de programadores está configurado para ser utilizado. Este mesmo repositório pode incluir scripts e fragmentos IaC que os fluxos de trabalho/pipelines utilizam.
2. Para permitir que estes fluxos de trabalho/pipelines interajam com o sistema a jusante adequado, as operações ou outros membros da equipa de engenharia da plataforma podem adicionar os segredos necessários no repositório central. Veja GitHub Actions e documentação do Azure DevOps para obter detalhes sobre como fazê-lo ou pode optar por centralizar os segredos com algo como o Azure Key Vault.
3. Estes fluxos de trabalho/pipelines podem, em seguida, seguir um modelo em que publicam quaisquer entidades resultantes como um artefacto de compilação/implementação (documentos do GitHub, documentos do Azure DevOps).
4. Durante uma execução, o fornecedor da plataforma de programadores pode, em seguida, watch o estado do fluxo de trabalho/pipeline e atualizar o estado do ciclo de vida no orquestrador até estar concluído. Por exemplo, pode utilizar web hooks com GitHub Actions e ganchos de serviço com os Pipelines do Azure para controlar as atualizações.
5. Depois de concluído, o fornecedor pode consumir o artefacto publicado para inclusão no gráfico da plataforma de programadores, conforme necessário.

Por fim, pode configurar este fornecedor de plataforma de programador para produzir um conjunto de modelos no gráfico da plataforma de programadores que referencia o repositório e fluxo de trabalho/pipeline adequados, juntamente com entradas para uma determinada tarefa.

O melhor de utilizar o seu sistema CI/CD é que, muitas vezes, estão configurados para suportar a execução de CLIs arbitrárias, pelo que não precisa de uma integração exclusiva de primeira classe para tudo o que faz. Pode adicioná-los ao longo do tempo, conforme necessário.

Muito do que é descrito neste exemplo aplica-se à forma como os outros tipos de fornecedores podem funcionar. Também é importante ter em atenção que a utilização de GitHub Actions ou pipelines do Azure neste contexto não requer que também os utilize para os seus pipelines ci/CD reais.

Outros exemplos

Eis alguns exemplos de outros tipos de fornecedores de plataformas de programadores que podem processar modelos.

Exemplo	Descrição
Operações de controlo de origem	Em alguns casos, poderá ter de criar ou atualizar um repositório, submeter um PEDIDO ou executar outra operação relacionada com o controlo de origem. Embora os motores de fluxo de trabalho assíncronos gerais possam gerir este tipo de operações, ser capaz de realizar operações básicas do Git sem um pode ser útil.
Aprovisionadores de infraestrutura	Embora GitHub Actions e os Pipelines do Azure funcionem bem para gerir o aprovisionamento de infraestruturas, também pode optar por integrações mais diretas. Um fornecedor dedicado pode simplificar a configuração e evitar sobrecargas. Serviços como Ambientes de Implementação do Azure ou Terraform Cloud estão mais diretamente focados em ativar o aprovisionamento baseado em modelos IaC e de forma segura e segura. Outros exemplos podem incluir itens como a criação de espaços de nomes do Kubernetes para aplicações em clusters partilhados ou a utilização do git com fluxos de trabalho do GitOps com o Flux ou o CD do Argo como um tipo específico de fornecedor. Modelos ainda mais centrados na aplicação, como o projeto experimental de incubação radius OSS com as suas próprias CLIs, podem ter os seus próprios fornecedores de plataformas de programador ao longo do tempo. O mais importante é procurar e planear a extensibilidade para que possa adaptar-se.
Estruturação/propagação de aplicações	Os modelos de aplicação são uma parte importante de onde a engenharia de plataformas leva ao longo do tempo. Pode suportar o seu motor de modelo à escolha ao fornecer um fornecedor de plataforma de programador dedicado que foi concebido para estruturar não só uma árvore de origem de aplicações, mas também criar e enviar conteúdos para um repositório de código fonte e adicionar as entidades resultantes ao gráfico. Cada ecossistema tem a sua própria preferência de estruturação de aplicações, seja Yeoman, cookiecutter ou algo como o Azure Developer CLI, pelo que o modelo de fornecedor aqui pode permitir-lhe suportar mais do que uma das suas mesmas interfaces. Aqui novamente, é a extensibilidade que é fundamental.
Processos manuais	Quer esteja a gerar automaticamente um PR para aprovação manual ou passos de fluxo de trabalho manuais para pessoas não programadoras responderem com algo como o Power Platform, o mesmo modelo baseado em modelos pode ser utilizado num fornecedor de plataforma de programador. Pode até mover para passos mais automatizados ao longo do tempo.

Embora possa não precisar de todos estes fornecedores para começar, pode ver como a extensibilidade através de algo como um fornecedor de plataforma de programador pode ajudar as suas capacidades de automatização a crescer ao longo do tempo.

Utilizadores e equipas

A engenharia de plataformas é inerentemente um caso de vários sistemas, pelo que é importante planear como uma base self-service deve lidar com os problemas mais desafiantes com a integração destes sistemas em conjunto. Nesta secção, vamos abordar uma estratégia para enfrentar desafios comuns com identidades, utilizadores e equipas.

Primeiro, considere estas duas recomendações:

Recomendação	Descrição
Integrar a API da plataforma de programadores diretamente com o seu fornecedor de identidade para uma segurança ideal	Para proteger a API da plataforma de programadores, recomendamos a integração direta com um fornecedor de identidade, como Microsoft Entra ID dada a sua identidade robusta e as capacidades de controlo de acesso baseado em funções (RBAC) do Entra ID. Existem muitas vantagens em utilizar diretamente os SDKs e APIs nativos de um fornecedor de identidade (por exemplo, através do MSAL Entra ID) e não através de uma abstração. Pode impulsionar a segurança ponto a ponto e confiar no mesmo modelo RBAC ao longo de todo, garantindo que as políticas de acesso condicional são continuamente avaliadas (ao contrário de apenas no momento do início de sessão).
Utilizar integrações de grupos de fornecedores de identidade e início de sessão único em sistemas a jusante	As integrações de início de sessão único (SSO) devem utilizar o mesmo fornecedor de identidade e inquilino que está a utilizar para a API da plataforma de programadores. Além disso, certifique-se de que tira partido do suporte para protocolos como o SCIM para ligar em grupos de fornecedores de identidade (como grupos do AD). Ligar estes grupos de fornecedores de identidade a permissões de sistema a jusante nem sempre é automático, mas, no mínimo, pode associar manualmente a identificação de grupos de fornecedores aos conceitos de agrupamento de cada ferramenta sem gerir manualmente a associação posteriormente. Por exemplo, pode combinar o suporte do Utilizador Gerido Empresarial (EMU) do GitHub, juntamente com tirar partido manualmente da capacidade de associar grupos de fornecedores de identidade às equipas do GitHub. O Azure DevOps tem capacidades semelhantes.

Em seguida, vamos criar estas recomendações para criar um modelo para lidar com problemas mais desafiantes neste espaço.

Estabelecer o conceito de uma equipa para além de um único grupo de fornecedores de identidade

À medida que o seu percurso de engenharia de plataformas continua, provavelmente verá que os grupos de fornecedores de identidade são ótimos para gerir a associação, mas que vários grupos realmente precisam de se unir para formar o conceito de uma equipa para controlo de acesso baseado em funções (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 estão a trabalhar em conjunto. Para a agregação de dados, a ideia de uma equipa com várias funções é fundamental para a deteção de energia e a agregação de informações em locais como dashboards de relatórios. Por outro lado, um grupo é um conceito de fornecedor de identidade geral para um conjunto de utilizadores e foi concebido com a ideia de adicionar várias pessoas a uma função específica, em vez do contrário. Com o RBAC, uma equipa pode, portanto, relacionar-se com vários grupos de fornecedores de identidade através de diferentes funções.

A origem dos dados da sua equipa pode ser proveniente de alguns locais diferentes. Por exemplo, se estiver a utilizar as equipas como padrão de código (TaC), um fornecedor de plataformas de programadores pode watch para alterações de ficheiros num repositório e guardá-las num perfil de utilizador e num arquivo de metadados de equipa. Em alternativa, pode integrar diretamente com algo como um Projeto do Azure Dev Center que já tem estas construções RBAC principais disponíveis.

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

Embora algumas ferramentas/serviços de programação e operações integrem e utilizem diretamente conceitos de fornecedor de identidade, muitos abstraem-no na sua própria representação de um grupo ou utilizador (mesmo com SSO). Além de ativar o acesso entre ferramentas, esta realidade também pode colocar problemas na agregação de dados. Especificamente, poderá descobrir que as APIs no sistema a jusante utilizam os seus próprios identificadores em vez de identificadores do fornecedor de identidade (por exemplo: o ID do Objeto no Entra ID não é utilizado diretamente). Isto dificulta a filtragem e associação de dados ao nível do utilizador ou da equipa, a menos que possa mapear entre IDs diferentes.

Abordar as diferenças ao nível da equipa e do grupo

Padrões como o TaC podem permitir-lhe armazenar e aceder a relações entre a equipa ou os identificadores de grupo de cada sistema para que possa mapear entre eles. Para recapitular, um repositório Git seguro e auditável torna-se a origem de uma equipa e os PRs fornecem uma interface de utilizador controlada para efetuar atualizações. Os sistemas CI/CD podem, em seguida, atualizar sistemas a jusante e manter as relações de identificador relacionados para a equipa que utilizou para o fazer.

Por exemplo, isto permite armazenar as seguintes relações nas chamadas à API:

Se preferir utilizar uma origem de dados que não seja ficheiros num repositório das suas equipas, este mesmo conceito geral pode ser aplicado através do orquestrador da plataforma de programadores para realizar a mesma coisa. Neste modelo, um fornecedor de plataforma de programadores para a origem dos dados da equipa pode acionar um evento de atualização de equipa que todos os outros fornecedores recebem e atuam conforme adequado.

Abordar os desafios do ID de utilizador

Outro desafio relacionado para o acesso e agregação de dados são as diferenças de ID de utilizador. Tal como no caso da equipa, se utilizar uma integração sistema a sistema para consultar dados sobre um utilizador, não pode assumir que o ID nativo dos fornecedores de identidade (por exemplo, O ID do Objeto para Entra ID) suporta uma determinada API. Aqui novamente, o armazenamento de um mapeamento para um ID de utilizador que está a aceder aos dados através da API da plataforma de programadores pode ajudar. Por exemplo, considere o GitHub:

Para cada sistema, se conseguir fazer uma pesquisa de um ID de utilizador noutro sistema através de uma API sem um token de utilizador, um determinado fornecedor de plataforma de programador pode gerar este mapeamento de imediato. Em alguns casos, isto pode complicar-se, uma vez que poderá ter de executar esta operação em massa e colocar em cache os resultados para referência para manter o desempenho.

Recue na utilização de vários tokens de utilizador

Para situações em que os fornecedores precisam de aceder a dados ao nível do utilizador sem uma forma de fazer a tradução de ID de utilizador que funcione, a API da plataforma de programador pode ser configurada para gerir vários tokens de utilizador. Por exemplo:

1. A API da plataforma de programador pode suportar uma cache de tokens de utilizador específicos do fornecedor para utilização com sistemas a jusante.
2. Qualquer interação com um determinado fornecedor acionado pela API incluiria o token de utilizador do fornecedor, se disponível.
3. Para lidar com o caso em que nenhum token de utilizador estava disponível, o fornecedor acionaria um fluxo OAuth para obter um.
4. Para começar, a API da plataforma de programadores devolveria um URI de autenticação para um fluxo OAuth com um URI de redirecionamento que foi transmitido para o fornecedor. O URI transmitido incluiria um código nonce/one-time-use.
5. Em seguida, a API devolve uma resposta "não autenticada" com o URI.
6. Qualquer UX pode, em seguida, utilizar este URI para impulsionar o fluxo de autenticação adequado num browser.
7. Assim que o redirecionamento ocorrer, a plataforma de programador receberá o token de utilizador necessário e coloca-o em cache para referência futura juntamente com o ID de utilizador.
8. Em seguida, o cliente pode repetir a chamada à API, o que seria bem-sucedido.

Este conceito descreve uma forma de lidar com a autenticação complicada, uma vez que pode reutilizar IDs sempre que possível e não precisa de manter URIs de redirecionamento separados por sistema a jusante.

Agregar dados e fornecer capacidades adicionais

Utilizar ligações profundas com conhecimento do contexto para ferramentas e sistemas de relatórios

Até este ponto, temos vindo a falar sobre o aspeto da automatização do espaço problemático. Só isto pode ser um longo caminho, uma vez que a IU pode utilizar valores nas entidades devolvidas durante a automatização para criar ligações profundas para outros sistemas para a equipa.

Mesmo quando não estão relacionados com a automatização, os fornecedores de plataformas de programadores podem emitir qualquer tipo de entidade necessária. No entanto, geralmente, não quer trazer todos os dados detalhados de toda a sua plataforma de programador interna para o gráfico da plataforma de programadores. Os dashboards em soluções de observabilidade como o Grafana, Prometheus, DataDog ou code intelligence em produtos como o SonarQube e capacidades nativas em conjuntos de aplicações DevOps, como o GitHub e o Azure DevOps, são todos muito capazes. Em vez disso, a melhor abordagem é, muitas vezes, criar ligações profundas para estes outros sistemas. As suas entidades podem fornecer informações suficientes para criar ligações sem conter diretamente informações detalhadas, como conteúdos de registo.

Para casos em que pretende agregar e resumir dados entre ferramentas ou precisar de impulsionar métricas personalizadas, as soluções de relatórios do Power BI ou do Microsoft Fabric podem ser a sua próxima porta de chamada. Para intercalar dados de equipa, pode ligar-se à base de dados da Sua Fundação ou passar por uma API de plataforma de programador. Por exemplo, conforme descrito em Planear e priorizar, um local onde poderá querer um dashboard personalizado é medir o sucesso da sua plataforma de programador interna.

Seja seletivo com cada experiência adicional que criar

Embora possa ser apelativo recriar capacidades existentes em algo como um portal comum, tenha em atenção que também terá de mantê-lo. Esta é a área em que seguir uma mentalidade de produto é importante. As interfaces de estilo do dashboard são fáceis de conceber e compreender, mas os programadores poderão encontrar mais valor noutro local.

Dito isto, o modelo aqui permite-lhe utilizar dados agregados no grafo da plataforma de programadores para criar experiências de utilizador personalizadas. As entidades devem ter suporte incorporado para que possam ligar a um utilizador ou equipa. Isto permite à API da plataforma de programadores definir o âmbito da saída (juntamente com a utilização da indexação e da colocação em cache).

No entanto, mesmo quando precisa de criar um UX personalizado em vez de uma ligação profunda, a solicitação de todos os dados para o gráfico da plataforma de programadores ainda não é a melhor abordagem. Por exemplo, considere uma situação em que poderá querer apresentar registos no seu UX que já têm uma casa bem definida e gerida. Utilize informações nas entidades relacionadas para ajudar o seu UX a recolher informações diretamente a partir de sistemas a jusante.

Para começar, poderá ter de utilizar uma integração sistema a sistema para ligar, mas depois de implementar um dos modelos descritos em utilizadores e equipas, pode utilizar todos os IDs de utilizador/equipa armazenados a jusante ou tokens de autenticação de utilizador, se necessário.

Eis alguns exemplos de experiências comuns a considerar:

Exemplo	Descrição
Deteção e exploração	Como disse um técnico de engenharia de plataforma, "O que atrasa os projetos é a comunicação, não as competências dos programadores." – Daniel, Engenheiro da Cloud, Fortune 500 Media Company. Uma vez que o software é um desporto de equipa, a criação de uma interface de utilizador para ajudar a descobrir equipas e as entidades que possuem são normalmente uma das primeiras coisas a abordar. A pesquisa, a deteção e os documentos entre equipas ajudam a promover a reutilização e a ajudar a colaboração para o fornecimento ou suporte internos. As equipas também beneficiam de ter um único stop shop para encontrar coisas que possuem, incluindo ambientes, repositórios e outros recursos, como documentos.
Registo manual de ambientes ou recursos	Embora muitas coisas possam ser aprovisionadas e controladas através do orquestrador da plataforma de programadores, também poderá querer registar recursos ou ambientes que já existem ou ainda não estão automatizados. Um fornecedor simples que recolha informações de um repositório git e adicione informações aos recursos/a gestão do ambiente pode ser útil aqui. Se já tiver um catálogo de software, esta também se torna uma forma de integrá-lo no modelo.
Um catálogo de API	O controlo de APIs que os programadores devem utilizar pode ser um longo caminho. Se ainda não tiver algo, pode até começar com um repositório Git simples com uma série de ficheiros que representam APIs, o respetivo estado, utilizar PRs para gerir o fluxo de trabalho de aprovação. Estes podem ser adicionados ao gráfico da plataforma de programadores para que possam ser apresentados ou associados a outras entidades. Para capacidades mais robustas, pode integrar algo como o Centro de API da Microsoft ou outro produto.
Conformidade da licença	Em alguns casos, também poderá querer dar visibilidade sobre a conformidade da licença de software e o consumo de assentos. As plataformas de programadores também podem adicionar a automatização necessária para consumir lugares, mas mesmo que os assentos sejam atribuídos manualmente (por exemplo, através de um processo de RELAÇÕES Públicas num repositório git), visibilidade do programador sobre o que têm (e a capacidade do administrador de ver tudo).
Uma vista centrada na aplicação do Kubernetes	Quando utiliza um cluster do Kubernetes partilhado, pode ser difícil para os programadores localizar e compreender o estado das suas aplicações através do UX de administrador de cluster. Diferentes organizações optaram por lidar com este problema de forma diferente, mas utilizar um espaço de nomes para representar uma aplicação é uma forma bem conhecida de o fazer. A partir daí, pode utilizar entidades para estabelecer associações entre o espaço de nomes da aplicação no cluster e uma equipa e criar uma vista de estado mais focada no programador para a aplicação e fornecer ligações profundas para outras ferramentas ou UIs Web.

Experiências de utilizador

Diferentes funções na sua organização terão ferramentas ou serviços que representam um centro de gravidade para o seu trabalho diário. A solicitação destes sistemas pode dificultar que novas experiências de utilizador fora destes centros de gravidade ganhem tracção. Num mundo perfeito, os programadores, as operações e outras funções podem continuar a trabalhar num ambiente que faça sentido para eles - muitas vezes aqueles que já estão a utilizar.

Com isto em mente, planear várias interfaces de utilizador à medida que progride no seu percurso de engenharia de plataforma é uma boa ideia. Isto também pode proporcionar uma oportunidade para começar simples, provar valor e crescer para interfaces mais complexas à medida que a necessidade surge.

Integrar o que tem

Se leu os artigos Aplicar sistemas de engenharia de software e Refinar plataforma de aplicações , provavelmente identificou os sistemas que pretende continuar a utilizar. Em ambos os casos, avalie se pode melhorar e expandir o que tem antes de começar a criar novas experiências do zero. (Pergunte-se se as pessoas reagirão melhor a outra nova experiência de utilizador ou a uma versão melhorada de algo que têm agora?)

Algumas das ferramentas, utilitários ou aplicações Web que pretende continuar a utilizar serão personalizadas e estes são bons candidatos para melhorar. No entanto, não se esqueça de prestar atenção se as suas ferramentas e serviços favoritos têm um modelo de extensibilidade que pode utilizar. Terá muitas vantagens em começar por aí. Isto pode eliminar dores de cabeça de manutenção e segurança e permitir que se concentre no problema que está a tentar resolver

Por exemplo, poderá conseguir expandir as seguintes superfícies que já está a utilizar:

• Editores e IDEs.
• O seu conjunto de aplicações de DevOps.
• As 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 configurou do zero, uma vez que são centros de gravidade existentes. Ter uma API de plataforma de programador comum como linha de base irá permitir-lhe trocar itens, experimentar e mudar ao longo do tempo.

Considere extensões de editor Web para criar um portal de programador

Se estiver à procura de uma experiência baseada na Web para programadores, tenha em atenção que uma tendência recente é versões baseadas na Web de editores e IDEs. Muitos, como os que utilizam o VS Code, têm suporte de extensão. Com o VS Code, tudo o que criar para estas experiências Web traduz-se localmente para um benefício duplo.

Além de serviços como o GitHub Codespaces, vscode.dev é uma versão Web gratuita do editor do VS Code sem computação, mas inclui suporte para determinados tipos de extensões , incluindo as que utilizam webviews para IU personalizada.

Mesmo que os seus programadores não estejam a utilizar o VS Code em si, os padrões de UX são bem conhecidos e podem ser encontrados noutras ferramentas de programador. A utilização de vscode.dev pode fornecer uma base baseada na Web conveniente e familiar para experiências de programador, além da própria ferramenta.

Estes podem funcionar como um portal focado para programadores num formulário familiar que também pode traduzir para utilização local.

ChatOps

Outra oportunidade que é muitas vezes ignorada é a implementação de uma interface chatOps. Dado o aumento das interfaces baseadas em chat devido ao aumento de produtos de IA, como ChatGPT e GitHub Copilot, os comandos de ação ou comandos de barra podem fornecer uma forma útil de acionar fluxos de trabalho de automatização, verificar o estado e muito mais. Tendo em conta que a maioria das plataformas de CI/CD da aplicação têm suporte inicial para sistemas como o Microsoft Teams, Slack ou Discord, esta pode ser uma forma natural de integrar com outros programadores de interface de utilizador e funções de operações relacionadas que utilizam todos os dias. Além disso, todos estes produtos têm um modelo de extensibilidade.

Investir num novo portal para programadores

Partindo do princípio de que não tem um portal ou interface existente que pretenda utilizar como base, poderá decidir criar um novo portal de programador. Pense nisto como um destino em vez de um ponto de partida. Se ainda não tiver uma equipa de desenvolvimento a trabalhar consigo, iniciar este esforço é o momento de o fazer. Todas as organizações são diferentes, pelo que não há uma resposta de tamanho único para o que deveria estar neste tipo de experiência. Como resultado, não existe uma resposta de facto para um produto pré-embalado que possa criar e utilizar como está para algo como este hoje.

Para opções personalizadas autoalojadas, as arquiteturas gerais do portal Web não são novas e as suas equipas de desenvolvimento podem já estar a utilizar uma que possa utilizar. Se estiver a tentar obter algo à frente dos seus utilizadores para obter comentários antecipados, pode até começar com algo tão simples como o Power Pages de baixo código para se ligar à API de plataforma de programador comum.

Os esforços mais recentes do portal do programador são mais opinados. Por exemplo, Backstage.io é um toolkit de portal de programador personalizado criado inicialmente para satisfazer as necessidades do Spotify. Inclui uma CLI para ajudar a iniciar o arranque da árvore de origem, tal como o create-react-app faz para React.js.

Como um toolkit de portal, requer trabalho para se levantar e a personalização requer conhecimentos sobre TypeScript, Node.js e React. No entanto, o melhor é que, como toolkit, pode mudar quase tudo. Também tem o seu próprio catálogo de software e mecanismo de templating, mas a sua utilização não é necessária e tem uma forma bem definida de introduzir novos códigos de terceiros 1^e 3^rd denominados plug-ins.