Observação
Você também pode usar ADO2GH extension of the GitHub CLI para realizar sua migração. Confira Fase 1. Entender as migrações do Azure DevOps para o GitHub.
Etapa 0: Preparar-se para usar a API do GraphQL do GitHub
Para fazer consultas do GraphQL, você precisará escrever seus scripts ou usar um cliente HTTP como o Insomnia.
Para saber mais sobre como começar a usar a API do GraphQL do GitHub, incluindo como se autenticar, confira Realizar chamadas com o GraphQL.
Você enviará todas as consultas GraphQL para o destino da sua migração. Se você estiver migrando para o GitHub Enterprise Cloud com residência de dados, envie consultas para o ponto de extremidade do subdomínio da sua empresa do GHE.com.
Etapa 1: Obter a ownerId do destino de migração
Como proprietário de uma organização no GitHub Enterprise Cloud, use a consulta GetOrgInfo para retornar a ownerId, também chamada de ID da organização, na organização da qual você deseja ser proprietário dos repositórios migrados. Você precisará da ownerId para identificar seu destino de migração.
Consulta GetOrgInfo
query(
$login: String!
){
organization (login: $login)
{
login
id
name
databaseId
}
}
| Variável da consulta | Descrição |
|---|---|
login | O nome da sua organização. |
Resposta GetOrgInfo
{
"data": {
"organization": {
"login": "Octo",
"id": "MDEyOk9yZ2FuaXphdGlvbjU2MTA=",
"name": "Octo-org",
"databaseId": 5610
}
}
}
Neste exemplo, MDEyOk9yZ2FuaXphdGlvbjU2MTA= é a ID da organização ou ownerId, que usaremos na próxima etapa.
Etapa 2: Identificar a origem da migração
pt-BR:
Sua fonte de migração é sua organização do ADO.
`createMigrationSource` mutação
mutation createMigrationSource($name: String!, $ownerId: ID!) {
createMigrationSource(input: {name: $name, url: "https://dev.azure.com", ownerId: $ownerId, type: AZURE_DEVOPS}) {
migrationSource {
id
name
url
type
}
}
}
Observação
Lembre-se de usar AZURE_DEVOPS para type.
| Variável da consulta | Descrição |
|---|---|
name | Um nome para a origem da migração. Esse nome se destina à sua referência, ou seja, você pode usar qualquer cadeia de caracteres. |
ownerId | A ID da sua organização no GitHub Enterprise Cloud. |
`createMigrationSource` resposta
{
"data": {
"createMigrationSource": {
"migrationSource": {
"id": "MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA",
"name": "Azure DevOps Source",
"url": "https://dev.azure.com",
"type": "AZURE_DEVOPS"
}
}
}
}
Neste exemplo, MS_kgDaACQxYmYxOWU4Yi0wNzZmLTQ3NTMtOTdkZC1hNGUzZmYxN2U2YzA é a ID de origem de migração, que usaremos na próxima etapa.
Etapa 3: Iniciar a migração do repositório
Quando você inicia uma migração, um repositório individual e os dados complementares são migrados para um novo repositório do GitHub identificado por você.
Caso você deseje mover vários repositórios ao mesmo tempo da mesma organização de origem, coloque várias migrações na fila. É possível executar até cinco migrações de repositório ao mesmo tempo.
`startRepositoryMigration` mutação
mutation startRepositoryMigration (
$sourceId: ID!,
$ownerId: ID!,
$sourceRepositoryUrl: URI!,
$repositoryName: String!,
$continueOnError: Boolean!,
$accessToken: String!,
$githubPat: String!,
$targetRepoVisibility: String!
){
startRepositoryMigration( input: {
sourceId: $sourceId,
ownerId: $ownerId,
repositoryName: $repositoryName,
continueOnError: $continueOnError,
accessToken: $accessToken,
githubPat: $githubPat,
targetRepoVisibility: $targetRepoVisibility,
sourceRepositoryUrl: $sourceRepositoryUrl,
}) {
repositoryMigration {
id
migrationSource {
id
name
type
}
sourceUrl
}
}
}
| Variável da consulta | Descrição |
|---|---|
sourceId | A origem de migração id retornou da mutação createMigrationSource. |
ownerId | A ID da sua organização no GitHub Enterprise Cloud. |
repositoryName | Um nome de repositório exclusivo personalizado não usado atualmente por nenhum dos seus repositórios pertencentes à organização no GitHub Enterprise Cloud. Um problema de log de erros será criado neste repositório quando a migração for concluída ou tiver sido interrompida. |
continueOnError | Configuração de migração que permite que a migração continue ao encontrar erros que não causam falha na migração. Deve ser true ou false. Recomendamos fortemente definir continueOnError como true, de modo que a migração continue, a menos que o Importer não possa mover a origem do Git ou o Importer tenha perdido a conexão e não possa se reconectar para concluir a migração. |
githubPat | O personal access token da sua organização de destino no GitHub Enterprise Cloud. |
accessToken | Os dados do personal access token da origem. |
targetRepoVisibility | A visibilidade do novo repositório. Deve ser private, public ou internal. Se isso não estiver definido, seu repositório será migrado como privado. |
sourceRepositoryUrl | A URL do repositório de origem, usando o formato https://dev.azure.com/{organization}/{project}/_git/{repository}. |
Para ver os requisitos do personal access token, confira Fase 2. Gerenciar acesso.
Na próxima etapa, você usará a ID de migração retornada da mutação startRepositoryMigration para verificar o status da migração.
Etapa 4: Verificar o status da migração
Verifique a migração na ferramenta de migração corporativa.
Etapa 5: Validar a migração e verificar o log de erros
Leitura adicional
-
[AUTOTITLE](/migrations/ado/phase-6-follow-up-tasks) -
[AUTOTITLE](/migrations/ado/key-differences-between-azure-devops-and-github)