A Senior disponibiliza aos seus clientes duas modalidades de serviços em nuvem, adaptadas às diferentes necessidades operacionais e de infraestrutura:

• Produtos da Senior na nuvem pública: os clientes beneficiam-se do uso compartilhado e escalável de recursos computacionais, garantindo alta disponibilidade, serviços de TI otimizados e a manutenção dos padrões de privacidade e segurança equivalentes aos ambientes tradicionais On-Premises.
• Produtos da Senior na nuvem privada: modalidade destinada aos clientes com elevado volume de customizações ou necessidades específicas de operação e conformidade. Nessa configuração, os recursos computacionais são exclusivos e dedicados ao contratante.

A evolução dos produtos ocorre por meio da disponibilização de novas versões, que podem contemplar novas funcionalidades, melhorias de desempenho, correções de segurança e demais aprimoramentos. A forma de atualização varia de acordo com o ambiente utilizado pelo cliente, conforme os exemplos que se seguem:

• Nuvem pública ou privada da Senior: as correções e melhorias são disponibilizadas quando a versão incluir novas funcionalidades. A atualização deverá ser solicitada pelo cliente após a homologação de suas customizações e integrações.
• On-Premises: para clientes que hospedam e administram suas próprias aplicações, a responsabilidade pela atualização é do próprio cliente. As novas versões são disponibilizadas pela Senior/GAtec mediante solicitação por ticket no Zendesk ou por meio das entregas disponibilizadas no Portal do Cliente Senior.

Fases oficiais do ciclo de vida

O ciclo de vida das versões é dividido em fases sucessivas que orientam a disponibilização, manutenção, suporte e atualização do software ao longo do tempo. As datas correspondentes a cada fase são estabelecidas no Ciclo de vida das versões (cronograma oficial).

Release Candidate

Etapa em que a versão com novas funcionalidades consolidadas e testadas internamente é disponibilizada inicialmente para homologação por um grupo específico de clientes antes de sua liberação comercial.

Disponibilidade Comercial

Etapa em que a versão aprovada na fase anterior é liberada para os demais clientes da Senior. Nesta fase, recebe novas funcionalidades, melhorias, correções e atualizações previstas para o produto. Recomenda-se sempre manter o ambiente na versão em Disponibilidade Comercial.

Transição

Etapa em que a versão deixa de receber novas funcionalidades, mas permanece com suporte e manutenção conforme os critérios estabelecidos nesta PCVV. Nesta fase, o cliente deve planejar a adoção da próxima versão em Disponibilidade Comercial.

Pré-descontinuação

Etapa em que a versão inicia sua fase final do ciclo de suporte e manutenção da versão. Nesta fase, as entregas priorizam manutenções das correções de severidade alta e crítica, preservando a estabilidade e segurança enquanto ocorre a migração. O cliente deve priorizar a atualização para uma versão vigente, observando a data de descontinuação estabelecida Ciclo de vida das versões (cronograma oficial).

Descontinuada

Etapa em que a versão deixa de receber o seu ciclo de suporte e manutenção. Não recebe novas funcionalidades, suporte técnico, manutenções corretivas ou atualizações para atendimento às exigências legais. Permanecer nessa condição implica assumir riscos operacionais e de não conformidade.

Ciclo de vida das versões (cronograma oficial)

A tabela a seguir apresenta, por versão, as datas oficiais de Release Candidate, a disponibilidade comercial e o início da transição, pré-descontinuação e descontinuação. Essas informações orientam o planejamento de atualização e ajudam a priorizar as janelas de homologação.

As plataformas da GAtec utilizam um modelo de versionamento baseado no Semantic Versioning, adaptado às necessidades do produto. Confira os exemplos a seguir:

X.XX — Versão

Representa alterações de maior impacto no produto, tais como:

• Inclusão de novas funcionalidades;
• Evoluções tecnológicas e estruturais;
• Atualizações que contribuem para a modernização da solução e da infraestrutura
• Pode demandar ciclos de homologação mais abrangentes, especialmente em ambientes On-Premises.

YY — Release

Representa entregas incrementais e evolutivas do produto, tais como:

• Inclusão de funcionalidades de menor impacto;
• Organização das entregas previstas no roadmap;
• Comunicação estruturada das melhorias disponibilizadas aos clientes;
• Geralmente requer ciclos de homologação mais curtos quando comparados a uma nova versão.

ZZZ — Hotfix

Representa atualizações corretivas disponibilizadas de forma pontual, isto é:

• Permite a entrega ágil de ajustes prioritários;
• Preserva a estabilidade da solução;
• Possui processo específico de liberação e documentação.

A periodicidade das atualizações varia de acordo com o tipo de entrega, combinando previsibilidade operacional com agilidade na disponibilização de melhorias e ajustes, conforme previsto a seguir:

• Semanalmente: builds oficiais consolidam correções e ajustes recentes. Patches, fixes e hotfixes podem ser disponibilizados pontualmente, quando necessário.
• Trimestralmente: releases reúnem incrementos funcionais e melhorias de menor impacto, permitindo processos de homologação mais objetivos.
• Semestralmente ou anualmente: novas versões são disponibilizadas quando houver mudanças significativas no produto, evoluções tecnológicas ou atendimento a exigências legais relevantes. Em determinados cenários, essas atualizações podem demandar migração de esquema.

Atualizações por ambiente

• SaaS: em ambientes SaaS, a responsabilidade pelas atualizações é da equipe de infraestrutura da Senior Sistemas. As atualizações são realizadas mediante solicitação do cliente, conforme os procedimentos definidos para o ambiente.
• On-Premises: clientes On-Premises são responsáveis pelo planejamento e execução de suas próprias atualizações.

Para minimizar riscos durante o processo, recomenda-se:

• Manter um ambiente de homologação;
• Definir janelas apropriadas para atualização;
• Realizar backups antes da execução do procedimento;
• Prever um plano de rollback;
• Validar integrações, customizações e fluxos críticos antes da promoção para o ambiente produtivo.

Cabe ao cliente planejar a adoção de novos recursos e versões, observando os prazos estabelecidos no ciclo de vida. Também é dever do cliente avaliar os impactos das atualizações sobre suas customizações, integrações e processos internos, bem como promover a capacitação dos usuários para utilização dos recursos disponibilizados. As responsabilidades relacionadas ao planejamento técnico e à execução da atualização variam conforme o modelo de hospedagem:

• SaaS: o cliente é responsável por planejar e homologar a adoção da versão, validar seus processos, customizações e integrações e solicitar a atualização conforme os procedimentos estabelecidos pela Senior. A execução técnica da atualização do ambiente é de responsabilidade da Senior.
• On-Premises: o cliente é responsável pelo planejamento e execução da atualização de seus ambientes, incluindo os procedimentos técnicos necessários para garantir a segurança e a continuidade da operação.

Independentemente do modelo de hospedagem, recomenda-se validar integrações, customizações, relatórios e rotinas críticas, registrar as evidências de homologação e aprovações e acompanhar as liberações e o calendário de versões. Para assegurar uma atualização adequada e previsível, recomenda-se:

Planejamento e homologação

• Manter ambiente de testes com cópia dos dados do ambiente de produção, exceto diretórios e conexões;
• Validar integrações, customizações, relatórios e rotinas críticas;
• Formalizar janela de mudança e plano de comunicação interna.

Gestão de risco e continuidade

• Realizar backup completo antes de cada atualização;
• Manter plano de rollback documentado e testado;
• Registrar evidências de homologação e aprovações.

Acompanhamento contínuo

• Acompanhar as liberações semanais e o calendário de releases;
• Priorizar a migração para a versão em disponibilidade comercial, assegurando conformidade legal e cobertura de suporte.

Senior provides its customers with two modalities of cloud services, adapted to different operational and infrastructure needs:

• Senior products in public cloud: customers benefit from the shared and scalable use of computational resources, guaranteeing high availability, optimized IT services and the maintenance of privacy and security standards equivalent to traditional On-Premises environments.
• Senior products in private cloud: modality intended for customers with high volume of customizations or specific needs for operation and compliance. In this configuration, computational resources are exclusive and dedicated to the contractor.

Product evolution occurs through the availability of new versions, which may include new features, performance improvements, security fixes and other enhancements. The form of update varies according to the environment used by the customer, as per the following examples:

• Senior public or private cloud: fixes and improvements are made available when the version includes new features. The update must be requested by the customer after homologation of their customizations and integrations.
• On-Premises: for customers who host and manage their own applications, the responsibility for the update is the customer's own. New versions are made available by Senior/GAtec upon request by ticket in Zendesk or through deliveries available in the Senior Customer Portal.

Official lifecycle phases

The version lifecycle is divided into successive phases that guide the availability, maintenance, support and software update over time. The dates corresponding to each phase are established in the Version lifecycle (official schedule).

Release Candidate

Stage in which the version with new consolidated and internally tested features is initially made available for homologation by a specific group of customers before its commercial release.

Commercial Availability

Stage in which the version approved in the previous phase is released to other Senior customers. In this phase, it receives new features, improvements, fixes and updates planned for the product. It is always recommended to keep the environment in the Commercial Availability version.

Transition

Stage in which the version stops receiving new features but remains with support and maintenance according to the criteria established in this PCVV. In this phase, the customer should plan the adoption of the next version in Commercial Availability.

Pre-discontinuation

Stage in which the version initiates its final phase of support and version maintenance cycle. In this phase, deliveries prioritize high and critical severity correction maintenance, preserving stability and security while migration occurs. The customer should prioritize the update to a current version, observing the discontinuation date established in Version lifecycle (official schedule).

Discontinued

Stage in which the version stops receiving its support and maintenance cycle. It does not receive new features, technical support, corrective maintenance or updates to meet legal requirements. Remaining in this condition implies assuming operational risks and non-compliance.

Version lifecycle (official schedule)

The following table presents, by version, the official dates for Release Candidate, commercial availability and the start of transition, pre-discontinuation and discontinuation. This information guides update planning and helps prioritize homologation windows.

GAtec platforms use a versioning model based on Semantic Versioning, adapted to product needs. Check out the following examples:

X.XX — Version

Represents major impact changes to the product, such as:

• Inclusion of new features;
• Technological and structural evolutions;
• Updates that contribute to the modernization of the solution and infrastructure;
• May require more comprehensive homologation cycles, especially in On-Premises environments.

YY — Release

Represents incremental and evolutionary product deliveries, such as:

• Inclusion of lower impact features;
• Organization of deliveries planned in the roadmap;
• Structured communication of improvements made available to customers;
• Generally requires shorter homologation cycles when compared to a new version.

ZZZ — Hotfix

Represents corrective updates made available in a timely manner, that is:

• Allows agile delivery of priority adjustments;
• Preserves solution stability;
• Has a specific release and documentation process.

The frequency of updates varies depending on the type of delivery, combining operational predictability with agility in making improvements and adjustments available, as provided below:

• Weekly: official builds consolidate recent fixes and adjustments. Patches, fixes and hotfixes can be made available on a timely basis, when necessary.
• Quarterly: releases bring together functional increments and lower impact improvements, allowing for more objective homologation processes.
• Biannually or annually: new versions are released when there are significant changes to the product, technological evolutions or compliance with relevant legal requirements. In certain scenarios, these updates may require schema migration.

Updates by environment

• SaaS: in SaaS environments, responsibility for updates is with Senior Sistemas infrastructure team. Updates are carried out upon customer request, according to procedures defined for the environment.
• On-Premises: On-Premises customers are responsible for planning and executing their own updates.

To minimize risks during the process, it is recommended to:

• Maintain a homologation environment;
• Define appropriate windows for update;
• Perform backups before executing the procedure;
• Plan for a rollback scenario;
• Validate integrations, customizations and critical flows before promotion to the production environment.

It is the customer's responsibility to plan the adoption of new features and versions, observing the deadlines established in the lifecycle. It is also the customer's duty to evaluate the impacts of updates on their customizations, integrations and internal processes, as well as to promote user training for the use of available features. The responsibilities related to technical planning and update execution vary according to the hosting model:

• SaaS: the customer is responsible for planning and homologating the version adoption, validating their processes, customizations and integrations and requesting the update according to procedures established by Senior. The technical execution of the environment update is Senior's responsibility.
• On-Premises: the customer is responsible for planning and executing updates of their environments, including the necessary technical procedures to ensure security and continuity of operation.

Regardless of the hosting model, it is recommended to validate integrations, customizations, reports and critical routines, record homologation evidence and approvals and follow version releases and calendar. To ensure an appropriate and predictable update, it is recommended to:

Planning and homologation

• Maintain testing environment with a copy of production environment data, except directories and connections;
• Validate integrations, customizations, reports and critical routines;
• Formalize change window and internal communication plan.

Risk management and continuity

• Perform complete backup before each update;
• Maintain documented and tested rollback plan;
• Record homologation evidence and approvals.

Continuous monitoring

• Follow weekly releases and release calendar;
• Prioritize migration to the commercial availability version, ensuring legal compliance and support coverage.

Senior disponibiliza a sus clientes dos modalidades de servicios en la nube, adaptadas a las diferentes necesidades operacionales y de infraestructura:

• Productos de Senior en la nube pública: los clientes se benefician del uso compartido y escalable de recursos computacionales, garantizando alta disponibilidad, servicios de TI optimizados y el mantenimiento de los estándares de privacidad y seguridad equivalentes a los ambientes tradicionales On-Premises.
• Productos de Senior en la nube privada: modalidad destinada a los clientes con elevado volumen de personalizaciones o necesidades específicas de operación y cumplimiento. En esa configuración, los recursos computacionales son exclusivos y dedicados al contratante.

La evolución de los productos ocurre por medio de la disponibilización de nuevas versiones, que pueden contemplar nuevas funcionalidades, mejoras de desempeño, correcciones de seguridad y demás mejoras. La forma de actualización varía de acuerdo con el ambiente utilizado por el cliente, conforme a los ejemplos que se siguen:

• Nube pública o privada de Senior: las correcciones y mejoras se disponibilizan cuando la versión incluya nuevas funcionalidades. La actualización deberá ser solicitada por el cliente después de la homologación de sus personalizaciones e integraciones.
• On-Premises: para clientes que alojan y administran sus propias aplicaciones, la responsabilidad por la actualización es del propio cliente. Las nuevas versiones son disponibilizadas por Senior/GAtec mediante solicitud por ticket en Zendesk o por medio de las entregas disponibilizadas en el Portal del Cliente Senior.

Fases oficiales del ciclo de vida

El ciclo de vida de las versiones se divide en fases sucesivas que orientan la disponibilización, mantenimiento, soporte y actualización del software a lo largo del tiempo. Las fechas correspondientes a cada fase se establecen en el Ciclo de vida de las versiones (cronograma oficial).

Release Candidate

Etapa en que la versión con nuevas funcionalidades consolidadas y probadas internamente se disponibiliza inicialmente para homologación por un grupo específico de clientes antes de su liberación comercial.

Disponibilidad Comercial

Etapa en que la versión aprobada en la fase anterior se libera para los demás clientes de Senior. En esta fase, recibe nuevas funcionalidades, mejoras, correcciones y actualizaciones previstas para el producto. Se recomienda siempre mantener el ambiente en la versión en Disponibilidad Comercial.

Transición

Etapa en que la versión deja de recibir nuevas funcionalidades, pero permanece con soporte y mantenimiento conforme a los criterios establecidos en esta PCVV. En esta fase, el cliente debe planificar la adopción de la próxima versión en Disponibilidad Comercial.

Pre-descontinuación

Etapa en que la versión inicia su fase final del ciclo de soporte y mantenimiento de la versión. En esta fase, las entregas priorizan mantenimientos de las correcciones de severidad alta y crítica, preservando la estabilidad y seguridad mientras ocurre la migración. El cliente debe priorizar la actualización para una versión vigente, observando la fecha de descontinuación establecida en Ciclo de vida de las versiones (cronograma oficial).

Descontinuada

Etapa en que la versión deja de recibir su ciclo de soporte y mantenimiento. No recibe nuevas funcionalidades, soporte técnico, mantenimientos correctivos o actualizaciones para cumplimiento de exigencias legales. Permanecer en esa condición implica asumir riesgos operacionales y de incumplimiento.

Ciclo de vida de las versiones (cronograma oficial)

La tabla siguiente presenta, por versión, las fechas oficiales de Release Candidate, la disponibilidad comercial y el inicio de la transición, pre-descontinuación y descontinuación. Esa información orienta el planeamiento de actualización y ayuda a priorizar las ventanas de homologación.

Las plataformas de GAtec utilizan un modelo de versionamiento basado en Semantic Versioning, adaptado a las necesidades del producto. Consulte los ejemplos a continuación:

X.XX — Versión

Representa cambios de mayor impacto en el producto, tales como:

• Inclusión de nuevas funcionalidades;
• Evoluciones tecnológicas y estructurales;
• Actualizaciones que contribuyen a la modernización de la solución y de la infraestructura
• Puede demandar ciclos de homologación más amplios, especialmente en ambientes On-Premises.

YY — Release

Representa entregas incrementales y evolutivas del producto, tales como:

• Inclusión de funcionalidades de menor impacto;
• Organización de las entregas previstas en el roadmap;
• Comunicación estructurada de las mejoras disponibilizadas a los clientes;
• Generalmente requiere ciclos de homologación más cortos cuando se comparan con una nueva versión.

ZZZ — Hotfix

Representa actualizaciones correctivas disponibilizadas de forma puntual, es decir:

• Permite la entrega ágil de ajustes prioritarios;
• Preserva la estabilidad de la solución;
• Posee proceso específico de liberación y documentación.

La periodicidad de las actualizaciones varía de acuerdo con el tipo de entrega, combinando previsibilidad operacional con agilidad en la disponibilización de mejoras y ajustes, conforme a lo previsto a continuación:

• Semanalmente: builds oficiales consolidan correcciones y ajustes recientes. Patches, fixes y hotfixes pueden ser disponibilizados puntualmente, cuando sea necesario.
• Trimestralmente: releases reúnen incrementos funcionales y mejoras de menor impacto, permitiendo procesos de homologación más objetivos.
• Semestralmente o anualmente: nuevas versiones se disponibilizan cuando haya cambios significativos en el producto, evoluciones tecnológicas o cumplimiento de exigencias legales relevantes. En determinados escenarios, esas actualizaciones pueden demandar migración de esquema.

Actualizaciones por ambiente

• SaaS: en ambientes SaaS, la responsabilidad por las actualizaciones es del equipo de infraestructura de Senior Sistemas. Las actualizaciones se realizan mediante solicitud del cliente, conforme a los procedimientos definidos para el ambiente.
• On-Premises: clientes On-Premises son responsables por el planeamiento y ejecución de sus propias actualizaciones.

Para minimizar riesgos durante el proceso, se recomienda:

• Mantener un ambiente de homologación;
• Definir ventanas apropiadas para actualización;
• Realizar backups antes de la ejecución del procedimiento;
• Prever un plan de rollback;
• Validar integraciones, personalizaciones y flujos críticos antes de la promoción al ambiente productivo.

Le corresponde al cliente planificar la adopción de nuevos recursos y versiones, observando los plazos establecidos en el ciclo de vida. También es deber del cliente evaluar los impactos de las actualizaciones sobre sus personalizaciones, integraciones y procesos internos, así como promover la capacitación de los usuarios para la utilización de los recursos disponibilizados. Las responsabilidades relacionadas con el planeamiento técnico y la ejecución de la actualización varían conforme al modelo de hospedaje:

• SaaS: el cliente es responsable por planificar y homologar la adopción de la versión, validar sus procesos, personalizaciones e integraciones y solicitar la actualización conforme a los procedimientos establecidos por Senior. La ejecución técnica de la actualización del ambiente es responsabilidad de Senior.
• On-Premises: el cliente es responsable por el planeamiento y ejecución de la actualización de sus ambientes, incluyendo los procedimientos técnicos necesarios para garantizar la seguridad y la continuidad de la operación.

Independientemente del modelo de hospedaje, se recomienda validar integraciones, personalizaciones, reportes y rutinas críticas, registrar las evidencias de homologación y aprobaciones y acompañar las liberaciones y el calendario de versiones. Para asegurar una actualización adecuada y previsible, se recomienda:

Planeamiento y homologación

• Mantener ambiente de pruebas con copia de los datos del ambiente de producción, excepto directorios y conexiones;
• Validar integraciones, personalizaciones, reportes y rutinas críticas;
• Formalizar ventana de cambio y plan de comunicación interna.

Gestión de riesgo y continuidad

• Realizar backup completo antes de cada actualización;
• Mantener plan de rollback documentado y probado;
• Registrar evidencias de homologación y aprobaciones.

Acompañamiento continuo

• Acompañar las liberaciones semanales y el calendario de releases;
• Priorizar la migración a la versión en disponibilidad comercial, asegurando conformidad legal y cobertura de soporte.