Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
O que este PR faz?
Este PR cria um arquivo para a catalogação da aplicação no Backstage Service Catalog.
(Este PR foi criado automaticamente para repositórios contindos na Planilha de System Mapping de GovTI.)
Abaixo segue algumas explicações sobre as formas de catalogação e como adicionar as informações adicionais.
Component
Um `Component` descreve um componente de software. Tipicamente, um componente:Parâmetros suportados
type
- (Required) O nome do tipo doComponent
. Os valores possíveis são:website
,service
,library
,cli
,infra-as-code
,mobile
edesktop
.lifecycle
- (Required) O estado de lifecycle doComponent
. Os valores possíveis são:production
: um componente produtivo, mantido e bem estabelecido;experimental
: um componente em estágios iniciais, não-produtivo. Esse lifecycle sinaliza que o componente não possui garantias de reliability e que os consumidores podem preferir não consumir esse componente no lugar de outros com lifecycle deproduction
;deprecated
: um componente no final de seu lifecycle. Pode ser descontinuado/removido em breve.owner
- (Required) Uma referência ao nome do time responsável pelo componente. O formato deve ser:<github-org>/<github-team>
. Veja o exemplo na subsessão abaixo.system
- (Opcional) Uma referência ao nome doSystem
que engloba esse componente.subcomponentOf
- (Opcional) Uma referência ao nome de outroComponent
que este componente faz parte. O formato aceito é:component:<nome-do-componente>
.providesApis
- (Opcional) Uma lista de referências aos nomes deAPIs
expostas por esse componente.consumesApis
- (Opcional) Uma lista de referências aos nomes deAPIs
que são consumidas por esse componente.dependsOn
- (Opcional) Uma lista de referências aos nomes deComponents
ouResources
que esse componente depende. O formato aceito é:<tipo-da-entidade>:<nome-da-entidade>
. Veja o exemplo na subsessão abaixo.O
Component
possui alguns metadados obrigatórios a mais quando comparado com outras entidades. Todos esses metadados devem ser inseridos no blocometadata
do manifesto. Abaixo estão definidos cada um dos campos.Annotations especiais
Os campos abaixo devem estar definidos dentro de
metadata.annotations
:legacy.stone.tech/owner-email
(Required) E-mail do owner doComponent
. O valor deve ser um e-mail válido.legacy.stone.tech/prod-date
- (Opcional) A data, no formatoyyyy-mm-dd
que a aplicação entrou em produção. Campo se torna Required sespec.lifecycle: production
.stone.tech/cloud-accounts
- (Opcional) Uma lista em formato de String separada por vírgulas que elenca todas cloud accounts que oComponent
está deployado. Campo se torna obrigatório sespec.lifecycle: production
estone.tech/on-prem-sites
estiverem omitidos. As clouds suportadas são:aws
,gcp
,azure
,ibm
eoracle
. O formato deve ser<cloud>/<account-name>
separado por vírgulas. Por exemplo:aws/pagarme-tools,gcp/sreplatform
.stone.tech/on-prem-sites
(Opcional) Uma lista em formato de String separada por vírgulas que elenca todos datacenters on-premises que oComponent
está deployado. Campo se torna obrigatório sespec.lifecycle: production
estone.tech/cloud-accounts
estiverem omitidos. Os valores possíveis são:atlanta1
,chicago1
,sp1
erio1
. O formato deve ser o nome do(s) datacenter(s) separado por vírgulas. Por exemplo:chicago1,atlanta1
.Labels especiais
Os campos abaixo devem estar definidos dentro de
metadata.labels
:stone.tech/endpoint-type
(Required) Enum que representa o tipo de endpoint exposto peloComponent
. As opções são:public
,private
,internal
enone
.legacy.stone.tech/internal-user-auth-base
(Required) Informa qual base de autenticação é utilizada peloComponent
. As opções são:sso
,own-user-base
not-applicable
eother
.legacy.stone.tech/customer-auth-method
(Required) Enum que representa o método de autenticação utilizado por usuários doComponent
. As opções são:api-key
,user-password
,other
enot-applicable
.legacy.stone.tech/handle-lgpd
(Opcional) String que representa um valor booleano indicando se algum ativo de infra associado aoComponent
realiza o processamento de Dados Pessoais ou Dados Pessoais Sensíveis, para apoiar a LGPD. Campo se torna obrigatório sespec.lifecycle: production
. Os valores possíveis são:"true"
ou"false"
.legacy.stone.tech/access-request-type
(Opcional) Informa qual é o método de solicitação de acesso aoComponent
. O campo se torna obrigatório sespec.lifecycle: production
. Os valores suportados são:jira
,service-now-stone
,service-now-pagarme
,github
,my-access
,email
,other
,not-applicable
.Links especiais
O campo
metadata.links
do Component possui 3 links obrigatórios para o Component sespec.lifecycle: production
, que são relacionados ao CD Pipeline, Monitoring e Incident Manager. Esses três nomes são os títulos obrigatórios que devem ser inseridos em cada um dos itens. Veja o exemplo abaixo:Demais itens são opcionais, mas esses três exemplificado acima são obrigatórios para o
Component
.Exemplos
API
Uma
API
descreve a interface que é exposta por umComponent
. EssaAPI
pode ser definida em diferentes formatos, como OpenAPI, AsyncAPI, GraphQL, etc.Parâmetros suportados
type
- (Required) O nome do tipo do schema daAPI
. Os valores possíveis são:openapi
,asyncapi
,graphql
egrpc
.lifecycle
- (Required) O estado de lifecycle daAPI
. Os valores possíveis são:production
: umaAPI
produtiva, mantida e bem estabelecida;experimental
: umaAPI
em estágios iniciais, não-produtiva. Esse lifecycle sinaliza que aAPI
não possui garantias de reliability e que os consumidores podem preferir não consumí-la no lugar de outras com lifecycle deproduction
;deprecated
: umaAPI
no final de seu lifecycle. Pode ser descontinuada/removida em breve.owner
- (Required) Uma referência ao nome do time responsável pelaAPI
. O formato deve ser:<github-org>/<github-team>
. Veja o exemplo na subsessão abaixo.definition
- (Required) A definição daAPI
com base no formato especificado no campotype
. A definição pode ser em texto puro ou referenciando um arquivo que exista no mesmo repositório que o manifesto está sendo criado. Veja os dois exemplos na subsessão abaixo.system
- (Opcional) Uma referência ao nome doSystem
que engloba essa API.Exemplos
API referenciando um arquivo
swagger.json
que contém sua definição:API com definição em texto puro:
Resource
Um `Resource` descreve um recurso de infraestrutura, por exemplo, _S3 buckets_, bancos de dados, tópicos de filas, etc.Parâmetros suportados
owner
- (Required) Uma referência ao nome do time responsável pelo recurso. O formato deve ser:<github-org>/<github-team>
. Veja o exemplo na subsessão abaixo.type
- (Required) O nome do tipo doResource
. Se oResource
representar um banco de dados, o valor deve serdatabase
. Para outros recursos de infraestrutura, o campo aceita qualquer valor.system
- (Opcional) Uma referência ao nome doSystem
que engloba essa API.dependsOn
- (Opcional) Uma lista de referências aos nomes deComponents
ouResources
que esse recurso depende. O formato aceito é:<tipo-da-entidade>:<nome-da-entidade>
. Veja o exemplo na subsessão abaixo.dependencyOf
- (Opcional) Uma lista de referências aos nomes deComponents
ouResources
que esse recurso é dependência. O formato aceito é:<tipo-da-entidade>:<nome-da-entidade>
.Labels especiais
Os campos abaixo devem estar definidos dentro de
metadata.labels
:stone.tech/dbms
(Optional) Enum que representa o Data Base Management System doResource
. Esse campo se torna obrigatório sespec.type: database
. As opções são:mysql
,postgresql
,sqlserver
emongodb
.Exemplos
Importante: verifique se este PR foi feito para a sua branch de trabalho correta. Caso negativo, altere a branch de destino!
Veja a nossa documentação explicando em mais detalhes sobre Backstage.
Em caso de duvidas, consultar nossa FAQ