Transforme uma instalação limpa do Windows em um ambiente completo de desenvolvimento com apenas um clique.
O One Click Restore é um Bootstrapper (Provisionador de Ambiente) desenvolvido em Go, cuja finalidade é automatizar a verificação, instalação e atualização das principais ferramentas utilizadas por desenvolvedores.
Ao invés de simplesmente instalar programas, ele atua como um Package Manager Orchestrator, coordenando diferentes gerenciadores de pacotes e métodos de instalação para reconstruir rapidamente um ambiente de desenvolvimento.
Quem já precisou formatar o Windows sabe o tempo perdido reinstalando manualmente:
- Git
- Go
- Node.js
- Python
- Java
- Rust
- .NET
- VS Code
- Flutter
- CMake
- GCC
- entre outras ferramentas.
O objetivo deste projeto é eliminar esse processo repetitivo.
Basta executar o programa para que ele:
- verifique quais ferramentas já existem;
- descubra suas versões instaladas;
- consulte versões mais recentes quando possível;
- pergunte se deseja instalar componentes ausentes;
- utilize automaticamente o melhor método de instalação disponível;
- reconstrua o ambiente de desenvolvimento.
Imagine o seguinte cenário:
"Pegue um Windows recém-instalado e transforme-o automaticamente em uma máquina pronta para desenvolvimento."
É exatamente isso que este projeto faz.
Início
│
Verifica privilégios de administrador
│
Percorre todas as ferramentas cadastradas
│
Para cada ferramenta
│
Existe?
│
┌────┴─────┐
│ │
Sim Não
│ │
│ Pergunta se deseja instalar
│ │
│ │
│ Instala automaticamente
│ │
│ │
│ Atualiza o PATH
│ │
│ │
│ Verifica novamente a instalação
│
│
Consulta versão mais recente
│
│
Existe atualização?
│
│
Atualiza
│
Fim
O projeto não depende de um único gerenciador de pacotes.
Ele é capaz de utilizar automaticamente:
- Chocolatey
- Winget
- Scoop
- Download direto
- Scripts PowerShell
Isso aumenta significativamente a compatibilidade entre diferentes ambientes Windows.
- Verificação automática de ferramentas instaladas
- Extração de versão utilizando Regex
- Captura de stdout e stderr
- Atualização automática do PATH
- Instalação via múltiplos gerenciadores
- Instalação silenciosa quando suportada
- Atualização automática de ferramentas
- Consulta à API do GitHub para versões recentes
- Instalação opcional de componentes não essenciais
- Compatível com execução em modo Administrador
- Go
- Node.js
- Python
- Rust
- Java
- PHP (opcional)
- Ruby (opcional)
- R (opcional)
- .NET SDK
- Flutter (opcional)
- GCC / MinGW
- Git
- CMake
- Visual Studio Code
- Chocolatey
- Scoop
Embora seja um utilitário relativamente pequeno, ele utiliza diversos recursos recomendados na biblioteca padrão do Go.
Uso de os/exec com captura simultânea de:
- stdout
- stderr
- stdin
Isso evita problemas comuns, como ferramentas que escrevem informações de versão apenas na saída de erro (por exemplo, Java e Dart).
As requisições utilizam:
http.Client{
Timeout: ...
}ao invés de chamadas diretas com http.Get().
Isso evita bloqueios indefinidos durante downloads e consultas de versão.
As respostas da API do GitHub são processadas utilizando:
json.NewDecoder(resp.Body)em vez de carregar todo o conteúdo em memória.
Cada ferramenta possui um parser próprio de versão.
Exemplo:
git version 2.49.1.windows.1
↓
2.49.1
Essa abordagem permite tratar diferentes formatos de saída sem depender de lógica específica para cada ferramenta.
Após instalar um programa, o Windows normalmente ainda não atualiza o PATH da sessão atual.
O projeto resolve esse problema recarregando automaticamente as variáveis de ambiente através do Registro do Windows.
Isso evita reiniciar o terminal após cada instalação.
Uma das decisões mais interessantes deste projeto foi modelar as ferramentas como dados.
Ao invés de escrever inúmeros blocos como:
if tool == "git" { ... }
if tool == "node" { ... }
if tool == "go" { ... }foi criada uma estrutura central:
type Tool struct {
...
}Cada ferramenta descreve:
- comando
- regex de versão
- métodos de instalação
- categoria
- gerenciadores compatíveis
Ou seja, o comportamento da aplicação é dirigido pelos dados.
O projeto já é bastante funcional.
Entretanto, algumas melhorias arquiteturais podem torná-lo ainda mais extensível.
Atualmente funções como:
processTool()installTool()
executam diversas responsabilidades ao mesmo tempo:
- impressão
- validação
- instalação
- atualização
- interação com o usuário
- verificação de versão
Uma evolução natural seria separar essas responsabilidades em serviços especializados.
Exemplo:
ToolService
↓
VersionChecker
↓
Installer
↓
EnvironmentManager
Cada componente teria apenas uma responsabilidade.
Hoje a escolha do método de instalação ocorre através de diversos switch.
Uma abordagem mais flexível seria criar uma interface:
type Installer interface {
Install(Tool) error
}E implementações específicas:
- ChocolateyInstaller
- ScoopInstaller
- WingetInstaller
- DownloadInstaller
Assim, adicionar novos gerenciadores não exigiria modificar código existente.
Esse é um excelente exemplo do princípio Open/Closed do SOLID.
Hoje a consulta da versão mais recente depende de condicionais baseadas no nome da ferramenta.
Uma alternativa seria cada ferramenta possuir seu próprio provedor:
type VersionProvider interface {
LatestVersion() (string, error)
}Implementações possíveis:
- GitHubProvider
- WingetProvider
- WebsiteProvider
- ManualProvider
Isso elimina condicionais extensas e facilita a manutenção.
Outra melhoria seria remover a responsabilidade de interpretar versões da estrutura Tool.
Cada parser poderia implementar:
type VersionParser interface {
Parse(string) (string, error)
}Exemplos:
- GitParser
- JavaParser
- NodeParser
- DartParser
Hoje as instalações acontecem em sequência.
Entretanto, muitas delas são independentes.
Uma possível evolução seria utilizar goroutines com um Worker Pool, permitindo instalar múltiplas ferramentas simultaneamente.
Isso reduziria significativamente o tempo total de provisionamento, desde que dependências compartilhadas (como Chocolatey e atualização do PATH) fossem sincronizadas corretamente.
Imagine uma oficina.
Hoje existe um funcionário chamado João.
João:
- atende clientes;
- troca óleo;
- vende peças;
- faz orçamento;
- lava carros;
- emite nota fiscal.
Ele faz tudo.
Se João faltar, toda a oficina para.
Agora imagine outra oficina:
Recepção
↓
Mecânico
↓
Financeiro
↓
Lavagem
Cada pessoa executa apenas uma função.
Se alguém precisar ser substituído, basta trocar aquela função específica.
É exatamente isso que os princípios SOLID procuram alcançar no desenvolvimento de software.
| Critério | Nota |
|---|---|
| Organização | 8.5 |
| Legibilidade | 9.0 |
| Robustez | 9.5 |
| Reutilização | 7.5 |
| Clean Code | 8.0 |
| SOLID | 7.0 |
| Go Idiomático | 8.5 |
| Propósito | 10.0 |
Na minha visão, o One Click Restore pode evoluir para algo ainda maior.
Ao invés de possuir a lista de ferramentas diretamente no código, ela poderia ser carregada de um arquivo JSON ou YAML.
Assim, o executável se tornaria um verdadeiro Engine de Provisionamento de Ambiente.
Adicionar uma nova ferramenta deixaria de exigir recompilar o programa.
Bastaria adicionar uma nova configuração, por exemplo:
- Docker
- PostgreSQL
- MySQL
- Android Studio
- Visual Studio
- Terraform
- Kubernetes
- AWS CLI
O comportamento passaria a ser dirigido pelos dados, e não por código específico.
Esse tipo de arquitetura tende a escalar muito melhor e reduz significativamente a necessidade de condicionais (switch e if) conforme o projeto cresce.
Contribuições são muito bem-vindas.
Caso queira ajudar a evoluir o projeto, fique à vontade para:
- fazer um Fork do repositório;
- abrir uma Issue com sugestões;
- enviar um Pull Request;
- melhorar a arquitetura seguindo princípios de Clean Code e SOLID;
- adicionar novos gerenciadores de pacotes;
- implementar novos provedores de versão;
- otimizar a concorrência utilizando goroutines.
Toda contribuição será muito bem-vinda.
Este projeto está disponível sob a licença definida neste repositório.
"Automatizar tarefas repetitivas não é apenas economizar tempo. É transformar conhecimento em software reutilizável."