Sucessão Do Proprietário De Uma Organização GitHub
Um plano de sucessão mantém o código e a administração a funcionar quando um fundador, responsável principal ou líder técnico deixa de poder atuar. A morte é uma razão para o preparar, mas o mesmo plano serve em caso de incapacidade, saída súbita, bloqueio de conta ou mudança normal de liderança.
O risco central é a concentração. Um único proprietário pode controlar membros, transferências, definições, integrações, políticas de segurança e faturação. Outros programadores podem continuar a enviar código sem terem autoridade para restaurar um runner, adicionar um responsável ou alterar uma configuração crítica.
Pelo menos dois proprietários
O GitHub avisa que os projetos podem tornar-se inacessíveis quando o único proprietário não está disponível. Por isso recomenda pelo menos dois proprietários.
Escolha pessoas ativas, fiáveis e ligadas ao projeto a longo prazo. Cada uma deve usar a sua própria conta, contactos atuais, autenticação forte e métodos de recuperação seguros. Uma conta de reserva esquecida não oferece continuidade real.
Mais proprietários não são automaticamente melhores. A função tem acesso administrativo completo. Um pequeno grupo responsável, acompanhado por funções operacionais mais limitadas, equilibra continuidade e segurança.
Separar propriedade e trabalho diário
A maioria das tarefas não exige direitos de proprietário. As funções de repositório vão de leitura e triagem a escrita, manutenção e administração. Conforme o plano, faturação, segurança, CI/CD e aplicações também podem ser separados.
Crie uma matriz de responsabilidades com pelo menos duas pessoas capazes para propriedade, pagamentos, alertas, repositórios, lançamentos, pacotes, Actions, runners, aplicações, webhooks, suporte e domínios.
Incluir serviços externos
As permissões GitHub não protegem um domínio, DNS, conta cloud, registo de pacotes, certificado de assinatura ou cartão empresarial. Registe o serviço, finalidade, responsável, substituto, renovação e local seguro das instruções. Não coloque segredos desprotegidos no documento.
Verifique sobretudo a publicação. Controlar o repositório não significa poder publicar no npm, PyPI, numa loja móvel ou num registo de contentores. Inclua segredos e variáveis de Actions, runners próprios, ligações cloud, GitHub Apps e webhooks.
Executar a transição e testar
A ordem indicada pelo GitHub é clara: adicionar o novo proprietário, confirmar acesso às definições, atualizar a faturação e só depois remover o proprietário que sai. O sucessor deve rever membros, regras, integrações e pagamentos e concluir uma tarefa supervisionada.
O plano de emergência deve indicar proprietários, contactos, serviços críticos, coordenador e localização das informações de recuperação. Evite transferências apressadas, eliminações em massa e partilha de palavras-passe. Verifique primeiro pagamentos, alertas, automações e lançamentos próximos.
Reveja o plano duas vezes por ano e após alterações de pessoal ou infraestrutura. A sucessão não é herdar a palavra-passe do fundador. É distribuir autoridade legítima antecipadamente para que código e comunidade continuem sem conceder poderes desnecessários.