Antes de configurar uma única aplicação, tem de decidir onde ficará a sua base de dados Odoo 19 Enterprise. A escolha do alojamento condiciona o que pode personalizar, quem controla o servidor, com que frequência tem de atualizar e quem é responsável pelas cópias de segurança.
O Odoo oferece três vias de alojamento: Odoo Online, Odoo.sh e on-premise (alojamento próprio). As três executam as mesmas aplicações Enterprise padrão, mas diferem muito assim que precisa de código personalizado, de acesso ao servidor ou de um ritmo de atualização específico.
Uma nota sobre as fontes: este guia segue a documentação oficial do Odoo para a versão 19.0. As regras e políticas de alojamento podem mudar, por isso confirme cada ponto relevante para o seu projeto numa base de dados de teste e face às condições da sua própria subscrição antes de se comprometer.
As três opções num minuto
- Odoo Online: o software como serviço do Odoo. O Odoo gere os servidores e a plataforma, e o cliente trabalha nas aplicações padrão e no Studio.
- Odoo.sh: a plataforma cloud oficial do Odoo para alojar e gerir o Odoo com código próprio, ligada a um repositório GitHub e organizada em ramos de desenvolvimento, staging e produção.
- On-premise: instala e executa o Odoo no seu próprio servidor, ou num servidor cloud alugado, e regista a base de dados com o código da sua subscrição Enterprise.
Personalização: o fator decisivo na maioria dos projetos
A documentação do Odoo é explícita: o Odoo Online é incompatível com módulos personalizados e com módulos da Odoo Apps Store. No Online configura as aplicações padrão e pode criar personalizações com o Studio, mas não pode instalar os seus próprios módulos Python.
O Odoo.sh foi concebido para código personalizado. Envia os seus módulos para um ramo do seu repositório GitHub e a plataforma deteta automaticamente as pastas que contêm módulos Odoo. Também é possível adicionar módulos comunitários públicos, por exemplo como submódulos Git.
O on-premise oferece a mesma liberdade que o Odoo.sh quanto a módulos personalizados, porque controla o servidor e os add-ons que este carrega. A diferença é que nada do que rodeia o código é gerido por si.
Uma regra prática: se os seus requisitos incluírem qualquer desenvolvimento personalizado em Python ou qualquer aplicação de terceiros da Apps Store, o Odoo Online fica excluído e a verdadeira decisão é entre o Odoo.sh e o on-premise.
Controlo e acesso
No Odoo Online gere a base de dados através do gestor de bases de dados do Odoo. A partir daí pode duplicá-la para testes, mudar-lhe o nome, descarregar uma cópia de segurança, iniciar uma atualização quando disponível, gerir nomes de domínio e transferir a propriedade. Não há acesso ao servidor nem à shell.
No Odoo.sh cada ramo inclui ferramentas de programador no navegador: uma shell web para comandos Linux básicos e psql, um editor online com consolas Python e Odoo shell, acesso SSH com a sua própria chave e um mail catcher que interceta os emails das builds que não são de produção.
O on-premise dá controlo total sobre o sistema operativo, o PostgreSQL, o reverse proxy e o ficheiro de configuração do Odoo. O guia de implementação do Odoo trata a segurança como um processo contínuo e enumera tarefas como servir o Odoo por HTTPS atrás de um reverse proxy, definir um filtro de bases de dados em servidores com várias bases de dados, usar um utilizador PostgreSQL que não seja superutilizador e desativar o gestor de bases de dados em sistemas expostos à internet.
Obrigações de atualização
Cada tipo de alojamento tem uma regra de atualização diferente. É um aspeto muitas vezes ignorado na seleção que mais tarde se torna urgente, por isso ponha-o em cima da mesa desde o primeiro dia.
- Odoo Online: segundo a documentação de atualização do Odoo, uma base de dados numa versão principal tem de ser atualizada de dois em dois anos, e uma base de dados numa versão intermédia tem de ser atualizada poucas semanas após o lançamento da versão seguinte. Se nada for feito até à data limite, o Odoo atualiza a base de dados automaticamente.
- Odoo.sh: após os três anos iniciais de suporte de uma versão, dispõe de mais dois anos para concluir a atualização e é notificado quando uma atualização é necessária.
- On-premise: pode manter-se na mesma versão indefinidamente. O Odoo não o recomenda, e diferenças de versão menores facilitam as atualizações.
Os módulos personalizados afetam todas as opções exceto o Online. O Odoo indica que uma base de dados com módulos personalizados não pode ser atualizada enquanto esses módulos não estiverem disponíveis para a versão de destino, e que torná-los compatíveis é responsabilidade de quem mantém o módulo.
Com o Odoo Enterprise, o serviço de atualização abrange as aplicações padrão, as personalizações do Studio enquanto o Studio estiver instalado e a subscrição ativa, e os desenvolvimentos cobertos por uma subscrição de manutenção de personalizações. Os módulos internos ou de terceiros sem esse contrato, a limpeza de dados existentes e a formação não estão incluídos.
O processo recomendado é o mesmo em todas as plataformas: pedir uma base de dados de teste atualizada, atualizar os módulos personalizados, testar exaustivamente, reportar problemas ao Odoo e depois planear a atualização de produção, durante a qual a base de dados fica indisponível.
Cópias de segurança e cópias de teste
Odoo Online: a documentação indica que as cópias de segurança são feitas diariamente ao abrigo do SLA do Odoo Cloud Hosting. Também pode descarregar uma cópia de segurança em ZIP a partir do gestor de bases de dados; se a base de dados for demasiado grande para isso, o Suporte do Odoo disponibiliza outro método.
Odoo.sh: a base de dados de produção tem cópia de segurança automática todos os dias, e cada cópia inclui o dump da base de dados, o filestore, os registos e as sessões. A documentação refere sete cópias diárias, quatro semanais e três mensais, com servidores de cópias de segurança dedicados que guardam cópias mensais adicionais. Também pode fazer cópias de segurança manuais das builds de produção e de staging.
As builds de staging e de desenvolvimento no Odoo.sh não têm cópia de segurança automática. As bases de dados de staging são duplicados neutralizados da produção que são removidos ao fim de algum tempo, e as bases de dados de desenvolvimento têm vida curta e são criadas a partir de dados de demonstração, por isso nunca guarde trabalho real apenas aí.
On-premise: as cópias de segurança são inteiramente da sua responsabilidade. Agende cópias de segurança tanto da base de dados PostgreSQL como do filestore, guarde cópias fora do servidor e teste regularmente a reposição.
Seja qual for a opção escolhida, as bases de dados de teste de atualização e as bases de dados de staging do Odoo.sh são neutralizadas: as ações agendadas são desativadas, o correio de saída é intercetado ou substituído e os conectores de pagamento e de envio passam para modo de teste. Isto protege a produção, mas as integrações têm de ser reativadas deliberadamente se as quiser testar.
Fatores de custo a comparar sem tabela de preços
Os preços dependem do seu contrato e mudam ao longo do tempo, por isso compare o que determina o custo e não os valores de referência.
- Âmbito da subscrição: o Odoo.sh exige um código de subscrição Enterprise que inclua o alojamento Odoo.sh, enquanto o on-premise usa uma subscrição Enterprise registada no seu próprio servidor, com uma base de dados associada por subscrição.
- Utilizadores: uma base de dados on-premise tem de se manter dentro do número de utilizadores da sua subscrição; ultrapassá-lo gera um aviso e um prazo limitado para corrigir o número antes de a base de dados expirar.
- Infraestrutura: no Odoo.sh dimensiona workers, armazenamento e builds de staging dentro da plataforma; no on-premise paga servidores, armazenamento, largura de banda e monitorização por conta própria, e o servidor tem de manter acesso de rede ao serviço de validação do Odoo.
- Pessoas: o on-premise precisa de alguém capaz de administrar Linux, PostgreSQL, HTTPS e atualizações de segurança; o Odoo.sh precisa de programadores à vontade com Git; o Odoo Online não precisa de nenhum deles.
- Ciclo de vida das personalizações: cada módulo personalizado tem de ser mantido e migrado em cada atualização, o que representa um custo recorrente no Odoo.sh e no on-premise, salvo se estiver coberto por uma subscrição de manutenção.
A quem se adequa cada opção
O Odoo Online adequa-se a empresas que conseguem trabalhar com o Odoo padrão e o Studio, querem o arranque mais rápido e aceitam o calendário de atualizações do Odoo. Empresas de comércio, serviços e retalho com processos padrão são candidatas típicas.
O Odoo.sh adequa-se a projetos que precisam de módulos personalizados ou aplicações de terceiros mas não querem gerir servidores, e que valorizam testar cada alteração numa cópia de staging da produção antes de entrar em funcionamento.
O on-premise adequa-se a organizações com uma equipa de TI interna, requisitos rigorosos de localização de dados ou de rede, integrações com hardware local ou necessidade de decidir exatamente quando ocorrem as atualizações.
Se está a considerar o Odoo Community, tenha em conta que o Odoo.sh exige um código de subscrição Enterprise e que o serviço de atualização gratuito descrito acima é uma vantagem do Enterprise, pelo que o Community é normalmente alojado internamente e atualizado por conta própria.
O Enterprise não é uma base de código separada: a documentação de instalação do Odoo descreve o repositório Enterprise como um conjunto de add-ons adicionais sobre o Community, pelo que uma instalação Enterprise alojada internamente precisa de ambos. Passar mais tarde do Community para o Enterprise é um projeto à parte, já que a documentação de atualização do Odoo não trata a mudança de edição como parte de uma atualização.
Mudar de tipo de alojamento mais tarde
A escolha não é definitiva, mas a mudança é mais fácil num sentido do que noutro.
- Do Odoo Online para o Odoo.sh ou on-premise: descarregue uma cópia de segurança a partir do gestor de bases de dados e importe-a ou reponha-a. As versões intermédias do Online não são suportadas noutros locais, pelo que pode ter de atualizar primeiro para a versão principal seguinte.
- Do Odoo.sh ou on-premise para o Odoo Online: todas as aplicações não padrão têm primeiro de ser desinstaladas, numa build de staging ou numa base de dados duplicada, e a migração propriamente dita é pedida através de um ticket de suporte do Odoo.
- Do on-premise para o Odoo.sh: use a importação no separador Backups do ramo de produção. A importação requer espaço livre equivalente a quatro vezes o tamanho do dump, substitui os dados atuais do ramo e desativa os servidores de correio de saída e as ações agendadas até reativar as que precisar.
Uma lista de verificação para a decisão
- Precisamos de algum módulo Python personalizado ou de algum módulo da Apps Store, agora ou num futuro previsível? Se sim, exclua o Odoo Online.
- Podemos aceitar o calendário obrigatório de atualizações do Odoo Online, ou precisamos de mais controlo sobre quando ocorre cada mudança de versão?
- Precisamos de uma cópia de staging da produção para testar cada alteração antes de entrar em produção?
- Temos, ou podemos contratar, pessoas para gerir Linux, PostgreSQL, HTTPS, monitorização e segurança de um servidor on-premise?
- Existem restrições de localização de dados, de rede ou de hardware que exijam servidor próprio?
- Quem é responsável pela verificação das cópias de segurança e pelos testes de reposição, e com que frequência serão feitos?
- Quem mantém e migra os nossos módulos personalizados em cada atualização, e isso está coberto por uma subscrição de manutenção?
Como a 1CBMS pode ajudar
A 1CBMS ajuda empresas no Egito e no Iraque a escolher o alojamento Odoo certo antes do início da implementação. Cruzamos os seus requisitos com o que cada plataforma permite, identificamos cedo qualquer necessidade de módulos personalizados, configuramos projetos Odoo.sh ou servidores on-premise com boas práticas de cópias de segurança e segurança, e planeamos as atualizações para que o seu sistema Odoo 19 Enterprise continue suportado. Contacte-nos através de www.1cbms.com para analisarmos o seu caso.