A Liferay busca comunicar claramente sobre a evolução, alterações importantes e descontinuação da funcionalidade pretendida. A política de manutenção e suspensão de uso fornece um guia sobre manutenção e suspensão de produtos.
Se um problema no código do produto impedir o seu desenvolvimento, nossos engenheiros de suporte fornecerão assistência para verificar qualquer defeito do produto Liferay. Ao relatar o problema, por favor forneça informações claras sobre a API específica, incluindo seus resultados esperados e reais, além de um aplicativo ou script simples que demonstre o problema (se disponível).
A Liferay resolverá problemas de acordo com a funcionalidade pretendida dos produtos. Talvez seja necessário que você altere algum desenvolvimento personalizado que influencie funcionalidades não intencionais.
Se uma funcionalidade esperada for relatada como um problema de API, o time de Serviços de Subscrição explicará a funcionalidade usando o código existente dos produtos, oferecendo a documentação de suporte ou um exemplo simples. Nos problemas com a API, a funcionalidade esperada não é apenas definida na seção Admin (documentação oficial), como também nos javadocs e listagens de webservices JSON. Por favor veja o artigo da Base de Conhecimento sobre a documentação da API Liferay para mais informações.
As políticas de Desenvolvimento de Código e Assistência de Arquitetura também orientam a resolução dos problemas de API Liferay reportados.
Entre em contato com o seu Account Executive ou Customer Experience Manager para discutir opções para obter assistência com seu desenvolvimento personalizado.
Uma vez relatados, os problemas entram no Workflow de Diagnóstico. Nesta etapa, o Serviço de Subscrição Liferay investiga o problema, tentando reproduzi-lo e, se aplicável, fornece uma resolução ao assinante. O Serviço de Subscrição Liferay deve, primeiramente, reproduzir quaisquer problemas relatados em uma versão não customizada dos produtos. Problemas que resultem de alguma customização dos produtos são de responsabilidade do próprio assinante. Os problemas que o time de Serviço de Subscrição não puder reproduzir permanecerão no Workflow de Diagnóstico e serão resolvidos caso a caso. Problemas que estão além da cobertura dos Serviços de Subscrição permanecerão no Workflow de Diagnóstico e serão resolvidos caso a caso. O seu Account Executive ou Customer Success poderá ajudá-lo com problemas não incluídos nos Serviços de Subscrição.
A Liferay buscará resolver defeitos reproduzíveis e não intencionais em versões de produtos não personalizadas por meio de patches ou alterações de configuração de acordo com a política de vida útil dos produtos. Os patches vão alterar o código-fonte dos produtos. O Serviço de Subscrição Liferay poderá fornecer documentação para tais alterações de código. Os assinantes são responsáveis por testar o patch e garantir que ele de fato resolve o problema em seu ambiente e, em seguida, informar os resultados ao Serviço de Subscrição Liferay em tempo hábil. Antes de instalar um patch, os assinantes devem fazer backup do seu sistema (por exemplo, código-fonte, arquivos, banco de dados). Para verificar se o patch não entra em conflito com nenhum desenvolvimento personalizado, os assinantes devem inicialmente testar o patch em um ambiente de homologação / testes. Os assinantes são responsáveis por quaisquer problemas com o desenvolvimento personalizado que surjam como resultado das resoluções de defeito dos produtos.
Atualizações de emergência, também conhecidas como hotfixes, são fornecidas caso a caso para componentes da Liferay que são implantados em ambientes de produção.
As Atualizações de Emergência serão disponibilizadas aos clientes de acordo com a gravidade e o impacto do defeito do produto, o ciclo de vida de implementação do cliente e a data de lançamento do Fix Pack, Service Pack ou Quarterly Release no ambiente afetado. Atualizações de emergência serão disponibilizadas para resolver defeitos catastróficos de produtos críticos para os negócios, conforme determinado pela Liferay. Eles também serão disponibilizados para limitar a quantidade de alterações feitas em um ambiente de produção ativo quando o ambiente de produção for impactado.
Por fim, para os lançamentos trimestrais (Quarterly Releases), as Atualizações de Emergência serão disponibilizadas sob demanda para lançamentos que foram emitidos nos últimos 365 dias, conforme determinado pela data em que o incidente foi relatado à Liferay e pela data em que o Quarterly Release foi liberado. Para esses fins, um lançamento é definido como um novo Quarterly Release lançado como um pacote ou um arquivo war com dependências OSGi; ou uma imagem Docker fornecida pela Liferay que inclua um novo lançamento trimestral.
A data de lançamento original do Quarterly Release será usada para determinar o tempo do lançamento e sua elegibilidade para Atualizações de Emergência. Uma nova imagem Docker fornecida pela Liferay que contenha alterações nos scripts Liferay, sistemas operacionais ou outra tecnologia interoperável, mas não inclui uma alteração na versão de lançamento trimestral (Quarterly Release), não se qualifica como uma nova versão.
Com o intuito de aumentar o tempo de atividade e disponibilidade, muitos assinantes implementam as reinicializações contínuas, que permite que os clientes tenham quase 100% de tempo de atividade, apesar da manutenção do servidor, desligando seletivamente uma instância da JVM em um cluster, executando a manutenção necessária nessa instância e, em seguida, reiniciando essa instância para incluí-la novamente no cluster. Esse processo é repetido até que todos os nós em um cluster tenham sido atualizados.
Definição da Cobertura
- A Liferay procura assegurar que o Liferay DXP 7.0 seja compatível com as práticas aceitas pelo mercado sobre as reinicializações contínuas para modificar propriedades do portal, instalar e desinstalar fix packs, instalar novos plugins ou módulos, atualizar plugins e módulos existentes, além de atualizar a versão do java e atender aos requisitos de reinicialização contínua.
- A Liferay procura assegurar que o Liferay DXP 7.0 seja compatível com as práticas aceitas pelo mercado sobre as reinicializações contínuas na medida em que os produtos são minimamente funcionais e capazes de responder a requisições limitadas durante a janela de manutenção definida. A funcionalidade mínima é definida pelos engenheiros de produtos da Liferay, caso a caso.
- A Liferay recomenda mitigar os riscos das atualizações de produção através das técnica de reinício contínuo, em oposição à técnica "hot deployment". No entanto, a viabilidade e implementação da técnica de reinício contínuo em um ambiente específico é de responsabilidade do próprio assinante.
- O Serviço de Subscrição Liferay irá fornecer orientações para determinar se uma atualização dos produtos Liferay atende aos requisitos de reinicialização contínua.
- A execução exitosa de técnicas de reinício contínuo envolve a interoperabilidade de várias tecnologias de terceiros. A configuração dessas tecnologias de terceiros, necessárias para executar uma reinicialização contínua em um cluster, é de responsabilidade do assinante.
Requisitos da Reinicialização Contínua
Qualquer função de manutenção realizada durante a utilização da técnica de reinício contínuo deve atender aos seguintes requisitos para ser testada como compatível com o Liferay DXP 7.0:
Instalação de Fix Packs
A instalação do Fix Pack utilizando uma técnica de reinicialização contínua é garantida como compatível com o Liferay DE desde que o novo fix pack seja reversível e, além disso, não existam fix packs não reversíveis entre o fix pack atualmente instalado e o fix pack desejado. Os fix packs que estão ou serão incluídos em um service pack contém alterações de banco de dados não reversíveis e, por isso, serão identificados como não reversíveis no Portal do Cliente, além de estarem listados na documentação de Alterações Importantes ou documentados no artigo da base de conhecimento Rolling Restarts - Breaking Changes.
Normalmente, os fix packs não reversíveis terminam com um zero. Todos os service packs contêm fix packs não reversíveis.
Novos Plugins ou Módulos
A implementação de novos plugins ou módulos utilizando a técnica de reinicialização contínua é garantida como compatível com o Liferay DE, desde que tais plugins ou módulos não excluam ou renomeiem quaisquer colunas do banco de dados ou modifiquem os dados de uma maneira a quebrar a compatibilidade com versões existentes. Qualquer atualização que exclua tabelas ou quebre a compatibilidade só deve ser executada enquanto todos os nós em um cluster estiverem desligados.
Atualizando Plugins ou Módulos
A atualização de plugins ou módulos já implementados utilizando a técnica de reinicialização contínua é garantida como compatível com o Liferay DXP 7.0, desde que tais plugins ou módulos não excluam ou renomeiem nenhuma coluna do banco de dados ou modifiquem os dados de maneira incompatível com a versão anterior. Qualquer atualização que exclua tabelas ou quebre a compatibilidade só deve ser executada enquanto todos os nós em um cluster estiverem desligados.
Há técnicas de desenvolvimento (por exemplo, implantação azul-verde) que podem acomodar alterações no esquema do banco de dados enquanto utilizam a técnica de reinicialização contínua. Os produtos da Liferay não utilizarão essas técnicas de desenvolvimento, pois a técnica requer pequenas alterações ao longo do tempo e a Liferay não pode garantir que as liberações dos produtos serão aplicadas na ordem correta.
A implantação azul-verde pode ocorrer no desenvolvimento customizado sem afetar a funcionalidade dos produtos Liferay. Por favor, consulte um Account Executive ou um Engagement Manager para explorar as opções relacionadas à assistência ao desenvolvimento.
Atualizações de Versões do Java
A atualização de uma instalação do Java JDK utilizando a técnica de reinicialização contínua é garantida como compatível com o Liferay DXP 7.0, dado que o incremento de versão seja limitado a uma versão secundária/minor. A atualização da versão principal da instalação do Java JDK utilizada pelo Liferay DXP não é garantida como compatível com a técnica de reinicialização contínua e só deve ser executada enquanto todos os nós em um cluster estejam encerrados.