Olá a todos. Enfrentei um problema enquanto desenvolvia no Discourse.
Geralmente, clono arquivos do Git,
Faço alterações,
Faço um commit no Git.
Meu colega faz um git pull
E recebe todas as minhas alterações.
Como posso implementar algo semelhante no Discourse?
Como posso fazer alterações para que outras pessoas possam instalá-las em casa?
Se você está desenvolvendo um tema ou um plugin para o Discourse, ambos podem ficar perfeitamente em um repositório Git.
Obrigado pela resposta. Sim, você está certo sobre o tema. E quanto à sincronização de componentes e configurações?
O código do seu plugin pode definir migrações e/ou conteúdos de seed conforme necessário. Eles também podem garantir que as configurações do site tenham o valor apropriado.
Quero clonar minha instalação completamente
Você pode fazer um backup e restaurar onde necessário.
Gosto de usar o S3 para backups e, assim, todos os sites podem compartilhar o mesmo conjunto de backups. Dessa forma, ao realizar um backup em produção, você pode restaurá-lo imediatamente nos ambientes de staging para verificar se funciona com os dados atuais.
O que é o S3? Gostaria de usá-lo.
Usando Armazenamento de Objetos para Uploads (S3 e Clones) Configurando uploads de arquivos e imagens para o S3 são os pontos de partida. Para backups, é bastante simples.
Backblaze e Wasabi são baratos. O storj.io também tem um produto que já usei para backups.
Minha opinião, e sem tirar o mérito dos comentários úteis aqui sobre backups, mas dando um passo atrás: não tenho certeza se vale a pena muito esforço sincronizar instalações do Discourse.
A menos que você pretenda contribuir com PRs no núcleo do Discourse, desenvolver plugins ou Componentes de Tema (TCs) é o caminho a seguir e oferece a solução mais robusta e eficiente para personalização.
O ponto principal ao desenvolver Plugins e Componentes de Tema é que eles serão implantados em várias instâncias do Discourse, sobre as quais você pode não ter controle, de qualquer forma.
Portanto, ter uma instância local do Discourse ligeiramente única para desenvolvimento é totalmente aceitável (dentro do razoável).
O fluxo de trabalho principal deve envolver manter o plugin ou TC atualizado em um repositório compartilhado, muito provavelmente no GitHub.
Concordo totalmente. Tenho alguns clientes com personalizações que não podem ser verificadas (ou são mais fáceis de verificar) contra seus dados reais, então eles realmente gostam de ver o site com os dados atuais.
Sim, isso é justo. Depende do que você está tentando fazer e de quem é a base de clientes (um único alvo ou vários clientes?) e de quanto controle você espera ter.
Obrigado a todos pelas dicas. Muito provavelmente, vou usar PRing no núcleo do Discourse. Portanto, preciso da capacidade de fazer upload da compilação para o Git e, a partir do Git, para o servidor.
Se você estiver abrindo um PR para o núcleo do Discourse, novamente, a configuração exata da instalação local não é crítica (apenas certifique-se de estar na versão mais recente), porque a contribuição de código é um processo muito controlado de qualquer forma, especialmente com casos de teste. Assim, uma pequena variação nas configurações ou no conteúdo dificilmente será um problema.
Normalmente, ao trabalhar em contribuições conjuntas, você faria um fork para o repositório da sua organização e trabalharia nele antes de abrir um PR?
Não, não estou trabalhando em contribuições conjuntas. Trabalho para uso pessoal.
Eu não quis dizer exatamente assim.
Como posso instalar o Discourse a partir de um fork do git?
Vou fazer alterações no núcleo do Discourse e adicioná-las ao meu repositório no git.
Então, estou confuso sobre por que você precisa sincronizar suas instalações.
Basta fazer um git clone do seu fork.
Normalmente, você não usaria o Docker para desenvolvimento, mas se for o caso, pode entrar no seu container e fazer o checkout do seu fork.
Por exemplo.
Agora, tenho o Discourse configurado.
Então, quando tudo estiver pronto, atualizo minha build.
Em seguida, continuo o desenvolvimento novamente. Estou alterando algumas configurações no painel de controle. Pode haver muitas delas.
Quando quiser atualizar minha build, precisarei atualizar as configurações também.
Nesse caso, terei que definir as configurações manualmente.
As configurações são persistentes e você está trabalhando sozinho, então por que a necessidade de focar em backup/sincronização?
(além disso, o título do tópico é confuso, então por que “em uma equipe”?)
Ao clonar ou fazer checkout, você não limpa o banco de dados (onde as configurações são armazenadas).
Você tem o controle de quando executar as migrações (se houver alguma). Caso contrário, o banco de dados deve permanecer estável.
