Na verdade, o seu problema real é fazer isso no ambiente de produção . Quero dizer, você deve reduzir o tempo de inatividade da melhor forma possível e planejar procedimentos de recuperação (rollback) caso algo dê errado.
Normalmente, eu não me importo com a "oficialidade" de um repositório, mas sim com "reputação". Eu não estou acostumado a pensar que repositórios públicos não-oficiais "abertos" injetam malware em pacotes (preocupação de segurança), e eu acho que se eles são populares e amplamente utilizados, eles são bem mantidos (preocupação de confiabilidade).
Se você está realmente preocupado em usar o repositório não oficial, você tem uma opção mais difícil: compilar a partir do código-fonte e sobrescrever o PHP quando o repositório oficial for atualizado. Isso introduz um risco.
Aqui está minha estratégia.
Primeiro, faça um instantâneo replicável do aplicativo . Colete arquivos, entradas de banco de dados e o que for necessário para iniciar o aplicativo em um novo servidor (no caso de você querer balancear a carga com 3, mas não quer realmente). Este será seu procedimento de reversão.
Em segundo lugar, crie um instantâneo do servidor com a instalação atual do PHP. Uma imagem completa do sistema é adequada. Mantenha-a como uma imagem dourada. Você fará backup do seu aplicativo junto com o servidor, mas tudo bem.
Em terceiro lugar, faça a compilação de origem, possivelmente tente primeiro a encenação.
Quarto, quando seu repositório oficial for atualizado, faça um novo instantâneo de aplicativo, restaure a antiga imagem do servidor dourado, atualize o PHP e atualize o aplicativo para o instantâneo que acabou de fazer.
Se algo der errado, você sempre terá:
- Um aplicativo de backup para restaurar. Eu não acho que você lida com milhares de transações por segundo, então a perda de dados pode ser mínima ou nula
- Uma imagem completa do servidor para o caso de algo ficar realmente muito ruim