Mudanças entre as edições de "Processo de desenvolvimento de software"

Edição atual tal como às 10h42min de 3 de março de 2016

[editar] Processo Operacional

O processo operacional define o modelo adotado para execução do ciclo de vida do projeto, ou seja, define a organização do trabalho técnico do projeto, incluindo as fases, as atividades e os artefatos.

Descreveremos aqui o processo operacional do PJe.

[editar] Contextualização do PJe

O objetivo principal do Conselho Nacional de Justiça (CNJ) com o PJe é manter um sistema de processo judicial eletrônico capaz de permitir a prática de atos processuais pelos magistrados, servidores e demais participantes da relação processual diretamente no sistema, assim como o acompanhamento desse processo judicial, independentemente de o processo tramitar na Justiça Federal, na Justiça dos Estados, na Justiça Militar dos Estados e na Justiça do Trabalho.

Além disso, o CNJ pretende convergir os esforços dos tribunais brasileiros para a adoção de uma solução única, gratuita para os próprios tribunais e atenta para requisitos importantes de segurança e de interoperabilidade, racionalizando gastos com elaboração e aquisição de softwares e permitindo o emprego desses valores financeiros e de pessoal em atividades mais dirigidas à finalidade do Judiciário: resolver os conflitos.

[editar] Estrutura gerencial do PJe

O sistema Processo Judicial eletrônico (PJe) é um software elaborado pelo CNJ a partir da experiência e da colaboração de diversos tribunais brasileiros.

O projeto é coordenado pela Comissão de Tecnologia da Informação e Infraestrutura do Conselho Nacional de Justiça. Na gestão direta, o projeto conta com um comitê formado por magistrados representando o CNJ e outros segmentos do judiciário.

Sob esse comitê, há a gerência do projeto propriamente dita, com a responsabilidade da gestão do projetos, gestão das mudanças e gestão da interoperabilidade.

O PJe, dentro do CNJ, funciona como uma estrutura virtual vinculada à Coordenação de desenvolvimento de sistemas que, por sua vez, é vinculada ao Departamento de Tecnologia da Informação (DTI). A denominação estrutura virtual é atribuída à unidade que não possui hierarquia de linha ou de staff e, por outro lado, também não pode ser considerada estrutura informal, uma vez que detém o reconhecimento institucional quanto à exclusividade de suas competências, com delimitações de autoridade e responsabilidade. (Verificar manual de organização do CNJ. )

O objetivo de se criar o PJe como uma estrutura virtual é aprimorar a gestão do Processo Judicial Eletrônico no âmbito do CNJ, obter um sistema de autoridade flexível (unidade de gestão do projeto responder a diferentes autoridades) e de compartilhar recursos (sistemas, pessoas, tecnologia). Esta estrutura é exclusivamente competente no âmbito do DTI pela gestão tática e operacional das atividades alusivas ao PJe. Descreveremos, a seguir, a estrutura criada. As atribuições detalhadas do gerente e dos assistentes podem ser encontradas no manual de organização do CNJ.

[editar] Gerente de projetos do PJe

O PJe tem característica de projeto, apesar de muitas vezes se parecer a uma operação. Nesse sentido, o Gerente de projetos tem atribuições semelhantes ao papel homônimo de tantas metodologias que utilizam os conceitos do PMBok em suas definições. Dentre as principais atribuições, encontram-se: controle de cronogramas, participação na definição de escopo, atribuição de responsabilidades e gerenciamento de comunicações.

[editar] Assistência em requisitos do PJe e capacitação

A assistência em requisitos é responsável pela análise de requisitos envolvendo definição e validação de funcionalidades do sistema, por prover os insumos para treinamentos e pela participação nos planejamentos e execuções de capacitações relacionadas ao PJe. E ainda deve firmar parcerias com outros órgãos que aderiram ao PJe de forma a criar multiplicadores de conhecimento. Além disso, essa assistência também responsabiliza-se pelas definições a respeito do processo operacional e da padronização dos artefatos produzidos no desenvolvimento do projeto.

Como contactar essa assistência:
- Enviar email para g-assistencia.requisitos.pje@cnj.jus.br
ou
- Mensagem no JIRA para o usuário g-assistencia.requisitos.pje

[editar] Assistência em desenvolvimento de sistemas do PJe

A assistência em desenvolvimento é responsável pelo desenvolvimento de melhorias do PJe, controlando o cronograma de desenvolvimento a fim de atender ao planejamento de versões.

Como contactar essa assistência:
- Enviar email para g-assistencia.desenvolvimento.pje@cnj.jus.br
ou
- Mensagem no JIRA para o usuário g-assistencia.desenvolvimento.pje

[editar] Assistência em atendimento e qualidade do PJe

A assistência em atendimento e qualidade é responsável pelos testes do PJe, pela centralização do atendimento ao público interno e externo e pelo controle de liberação de versões do sistema.

Como contactar essa assistência:
- Enviar email para g-assistencia.qualidade.pje@cnj.jus.br
ou
- Mensagem no JIRA para o usuário g-assistencia.qualidade.pje

[editar] Assistência em implantação e manutenção do PJe

A assistência em manutenção faz a gerência das atividades de correção de defeitos do PJe, planejando suas versões intermediárias para atendimento dos tribunais que têm PJe instalado.

Como contactar essa assistência:
- Enviar email para g-assistencia.manutencao.pje@cnj.jus.br
ou
- Mensagem no JIRA para o usuário g-assistencia.manutencao.pje

[editar] Organização do projeto

[editar] Conceitos sobre versões utilizados no PJe

Para entendimento do processo de desenvolvimento do PJe, são necessárias algumas explanações sobre conceitos de versões utilizados no sistema.

O fluxo de desenvolvimento é iniciado com o cadastro de uma demanda no sistema de controle de demandas adotado. No caso do CNJ, o sistema adotado foi o JIRA. No JIRA, a palavra “issue” significa “demanda”.

Todo o código fonte, assim como artefatos de banco de dados, são mantidos em um repositório GIT de controle de versões sob responsabilidade da equipe do PJe no CNJ. O GIT é um software que permite o controle de versões de forma descentralizada. Dessa forma, fábricas de desenvolvimento fora do CNJ podem participar do desenvolvimento do PJe, mas as alterações deverão sempre ser submetidas ao repositório central, alterações essas avaliadas pela equipe do PJe.

[editar] Regras de Versionamento

O esquema de numeração de versões adotado pelo CNJ é baseado no esquema adotado pela organização Apache Foundation. O esquema define que uma versão é composta por quatro números inteiros, MAJOR.MINOR.MICRO.PATCH onde:

O repositório GIT tem dois ramos de desenvolvimento principais: o principal (master), que recebe todas as modificações planejadas para a próxima versão, e o versão estabilizada (stable), que representa a versão atual em produção.

A figura abaixo apresenta em detalhes como o processo ocorre. O repositório possui dois branches principais: o master, que recebe todas as modificações planejadas para a próxima versão, e o stable, que representa a versão atual em produção. Praticamente todos os sistemas de controle de versão possuem algum suporte a ramificação (branching). Ramificação significa que o usuário pode divergir da linha principal de desenvolvimento e continuar a fazer seu trabalho sem mexer com esta linha. Através de ramificação, são criadas as versões minor, micro e os patches.

[editar] Geração de versões

Nas reuniões do Comitê Gestor Nacional que ocorrem mensalmente, são discutidas, entre outras questões, as prioridades para lançamentos de novas versões no PJe.

Dado esse direcionamento a partir dessa reunião, uma reunião de planejamento de liberação de versão ocorre envolvendo a fábrica do CNJ e as fábricas que participam do desenvolvimento do sistema, atualmente as da Justiça do Trabalho, da Justiça Eleitoral e do TJDFT.

Nessa segunda reunião são definidas as funcionalidades que entrarão como conteúdo da próxima liberação de versão, devidamente alinhado com a definição do Comitê Gestor Nacional. A partir dessa reunião, agrupam-se as demandas eleitas para serem desenvolvidas em funcionalidades a serem disponibilizadas na versão planejada (principal).

É criada, então, uma versão do PJe considerada uma versão estabilizada, onde não haverá requisições de subida de código, salvo correções de defeitos. Ao mesmo tempo, as novas funcionalidades são desenvolvidas na versão principal (original da estabilizada), onde são duplicadas as requisições de subida de código das correções.

Nesse meio tempo, podem ser lançadas versões de correção de defeitos. Atualmente as correções estão sendo liberadas através de versões patch mas, após migração de todos os tribunais para versão 1.5.0 ou superior, o PJe liberará correções através de versões micro.

Ao final do ciclo, é gerada internamente uma subversão da principal para homologação com um rótulo numerado iniciado pela letra "h" (exemplo:"1.6.0.h0"). São realizados testes durante duas semanas, e outras versões "h" são lançadas internamente com correções dos erros reportados. Se considerada estável, ou seja, se não tem defeitos bloqueadores, é lançada uma possível liberação de versão para os tribunais denominada "rc" (release candidate). Os tribunais terão duas semanas para homologarem a possível versão, votando pela homologação ou não através do JIRA. Uma vez aceita, a versão é liberada.

Para versões micro (atualmente, para versões patch), não são lançados os rótulos “h” e “rc”. Após testes internos, a versão é lançada diretamente.

[editar] Nomes das versões do sistema

As versões intermediárias do sistema receberão o nome de município brasileiro iniciado na letra de referência da versão, estas na ordem alfabética, que não contenha espaços ou caracteres especiais, obtidos a partir do nome das unidades federativas, essas na ordem alfabética inversa. Assim, por exemplo, temos: - Se não for encontrado município no estado que satisfaça estas regras, busca-se o município no próximo estado.

[editar] Processo de evolução do PJe

O PJe é um sistema, assim como tantos, em constante evolução. As correções e melhorias do PJe são propostas partindo das seguintes situações:
- usuários do sistema que detectam seu mal funcionamento ou necessidade de melhoria;
- testadores do PJe que detectam seu mal funcionamento em testes para liberação de versão e propõem melhorias de acordo com suas experiências de uso;
- gestores ou equipe interna do PJe que, tendo vivência com suas ocorrências e com o sistema em si, vislumbram pontos de melhoria e correção.

A partir de uma dessas situações, seguindo o modelo definido nas instruções de abertura de demandas no JIRA (ferramenta de controle de demandas do PJe), uma demanda deve ser aberta contendo a descrição da solicitação e suas principais definições. Após o registro no JIRA, a demanda flui através das seguintes atividades:

1. Triagem das demandas, abrangendo uma análise prévia validando as informações de preenchimento, especialmente quanto ao cumprimento das instruções para abertura de demandas e à reprodução do problema.
   1. Para o caso de demandas do tipo "Melhoria" ou "Nova funcionalidade", encaminhamento para análise da gerência técnica do PJe.
      1. Após avaliação, a demanda seguirá para análise de requisitos, e posteriormente para o desenvolvimento, conforme priorização dada pelo comitê.
   2. Para o caso de defeitos ou bugs em produção:
      1. Sendo a demanda aberta por um solicitante da equipe da justiça do trabalho, justiça eleitoral ou TJDFT, encaminhamento para equipe pertinente.
      2. Sendo a demanda aberta por um solicitante de outro grupo que não os citados acima, encaminhamento para desenvolvimento na equipe interna do CNJ.
2. Desenvolvimento da demanda
3. Homologação técnica da demanda
4. Testes da demanda

As atividades descritas acima foram especializadas de acordo com o tipo da demanda conforme mapeamos nos seguintes diagramas:

• Mapeamento das atividades de evolução do PJe iniciadas através de uma demanda de melhoria:

• Mapeamento das atividades de evolução do PJe iniciadas através de uma demanda de correção de defeito:

Na próxima subseção, detalhamos papéis e atividades exibidos nos diagramas anteriores com foco no atendimento do processo de evolução do PJe.

[editar] Descrição detalhada dos papéis e atividades

[editar] Solicitante

[editar] Abertura da demanda

O processo de evolução do PJe se inicia com a abertura de demandas no Jira. A atribuição de registrar a demanda é responsabilidade do solicitante, o que, em termos práticos, se traduz, na maioria das vezes, em usuários internos do PJe, ou seja, servidores dos tribunais. Os advogados podem também registrar suas demandas, mas essas chegarão à equipe do PJe através do atendimento externo do CNJ.

[editar] Gerência técnica

Composta pelos gestores da área técnica do PJe e atualmente contém os seguintes membros: o gerente de projetos do PJe(CNJ), o chefe da seção de sistemas de processamento judiciário(CNJ), dois magistrados do comitê gestor (Dr. Paulo e Dr. Carl - CNJ), o coordenador técnico do PJe no CSJT e líder da equipe de TI do PJe no TSE.

[editar] Aprovar e planejar

Todas as demandas abertas no JIRA que sejam dos tipos Melhoria ou Nova Funcionalidade que estiverem na situação 'Aberta' devem ser encaminhadas para essa gerência para validação, priorização e planejamento de novas versões do PJe.

[editar] Assistência em requisitos

[editar] Analisar requisitos

A análise de requisitos é, usualmente, acionada pela gerência técnica para detalhamento de requisitos de demandas autorizadas e priorizadas.

A assistência é a principal mantenedora da wiki do projeto, sítio disponível na Internet com restrições de edição que centraliza toda a documentação referente ao projeto.

Na análise de requisitos são produzidos os artefatos para detalhamento dos requisitos, sendo o nosso principal artefato o conjunto de casos de testes no Testlink, ferramenta que auxilia na manutenção dos casos de teste e na execução dos testes. Nos casos de teste, deverá se fazer referência a conteúdos inseridos na wiki do PJe, especialmente às regras (de negócio, de mensagens, de interface e de domínio) e à descrição da funcionalidade. As funcionalidades (que abrangem os conteúdos do manual de referência) são o conjunto de opções de uso do sistema. Procuramos evitar o termo caso de uso, já que não estamos utilizando desenvolvimento orientado a caso de uso, mas seria o conceito do caso de uso, sem o modelo padrão com todas aquelas seções comuns ao processo unificado. Geralmente as referências citadas aos documentos da wiki são feitas nos passos dos casos de teste, mas uma importante seção do caso de teste são as premissas de teste, que podem tanto fazer referência às regras e funcionalidades, como outras seções da wiki, como roteiros de configuração, orientações para desenvolvimento de fluxos, configuração inicial e instalação. Essas últimas seções contém orientações de configuração do PJe. Muitas vezes, para se testar uma aplicação, o testador deve se certificar que o sistema está pronto para realizar o teste, de forma a evitar que mal funcionamento decorrente de configuração equivocada seja confundido com defeito. Além do conjunto de casos de teste, outros artefatos como, protótipos de tela, diagramas e o que mais o analista julgar necessário para o entendimento da demanda devem ser produzidos, de preferência, em ferramentas de livre utilização (ou em formatos que todos os usuários possam ter acesso) e a disponibilização desses artefatos deve ser vinculada à demanda no JIRA.

Ao finalizar a documentação, a demanda deve ser enviada para a assistência em desenvolvimento para que fique pronta e seja posteriormente testada.

Ao iniciarmos a discussão sobre uma demanda, principalmente quando se trata de alguma funcionalidade maior, temos optado por evoluir um pouco mais os requisitos antes de abertura da demanda no JIRA fazendo registro em uma área de "rascunho" da wiki denominada Esboço de Melhorias. Ainda estamos trabalhando na melhor forma de apresentar essa seção, mas seu uso é opcional, apesar de ser recomendado, por facilitar a comunicação entre o "cliente" (solicitante da demanda) e o analista de requisitos.

[editar] Verificar comportamento esperado

A assistência em requisitos é frequentemente acionada pela assistência em manutenção para esclarecimentos necessários ao atendimento de uma demanda de defeito ou bug em produção.

Por vezes, o comportamento esperado vinculado a um defeito não está completamente documentado, dificultando sua resolução. Dessa forma, na comunicação entre as assistências, os requisitos são esclarecidos, permitindo a resolução da demanda. O comportamento é refletido na documentação, o que ocorre, muitas vezes, posteriormente à correção do defeito, visando o não represamento da solução para o tribunal.

[editar] Capacitação

Como principais detentores do conhecimento negocial a respeito do sistema, a assistência em requisitos também é responsável por construir documentações gerais do sistema, independente da demanda das melhorias. Dessa forma, a assistência auxilia na divulgação do conhecimento sobre o PJe como parte de sua competência de capacitação, além da responsabilidade de produção de materiais de treinamento e auxílio em sua condução.

[editar] Assistência em desenvolvimento

[editar] Desenvolver

A assistência em desenvolvimento é responsável pelo desenvolvimento de melhorias do PJe. Nesse sentido, seu trabalho é direcionado às versões futuras do PJe que estão em desenvolvimento, denominadas de versão principal.

Representamos, abaixo, o funcionamento dessa assistência.

[editar] Definição de arquitetura

Como colaboradores com as mudanças de código do PJe e principais usuários de sua definição arquitetural, a assistência em desenvolvimento do PJe também agrega às suas responsabilidades a definição e evolução da arquitetura do sistema, sob a coordenação do comitê gestor.

[editar] Assistência em manutenção

Os comportamentos dissonantes do PJe são tratados como defeitos e bugs em produção.

Os defeitos são problemas encontrados, via de regra, na fase de homologação de uma versão, ou seja, em ambiente de testes. Os bugs em produção são problemas encontrados no ambiente de produção.

A correção dos bugs em produção, em alguns casos, pode ocorrer através da geração de scripts de banco de dados, de forma a evitar que o tribunal precise evoluir sua versão para obter o funcionamento correto. Para essas situações, deve ser aberta uma outra demanda, se for o caso, para mapear a correção da versão que ocasionou o mal comportamento que teve que ser corrigido via script de banco de dados. Nesse último caso, o auxílio da assistência em atendimento e qualidade pode ser acionado.

Algumas vezes o mal comportamento não é detectado ou se diagnostica um problema de configuração no PJe que ocasionou o bug, não sendo, dessa forma, necessária a correção através de liberação de versão. Esses casos devem ser mapeados pela atividade de triagem, também responsabilidade da assistência em manutenção para o caso de bugs e defeitos. Caso seja detectado que o defeito não pode ser reproduzido ou que é o comportamento esperado do sistema, a triagem nem sequer enviará o defeito para correção, rejeitando a demanda.

[editar] Desenvolver

A assistência em manutenção deve planejar a resolução dos defeitos de acordo com a duração do período de liberação de versão. As liberações de versão de correção de defeitos/bugs em produção são realizadas, preferencialmente, de quatro em quatro semanas.

O desenvolvimento deve seguir direcionamentos dados na demanda pelo solicitante e pela triagem. Após resolução, deve documentar a solução na demanda, de forma a complementar o insumo para documentação que será realizada pela assistência em requisitos.

As correções são replicadas nas versões em desenvolvimento que, dentro do CNJ, são de responsabilidade da assistência em desenvolvimento.

Após finalizada, a demanda deve ser enviada para homologação técnica por parte de assistência em implantação.

Ao finalizar uma versão, a assistência em implantação deverá notificar a assistência em atendimento sobre a finalização da versão para que os procedimentos de preparação da versão sejam feitos, tornando a versão disponível para os usuários externos.

[editar] Assistência em atendimento e qualidade

A gestão dos ambientes de desenvolvimento, teste e homologação, assim como dos bancos de dados e de tarefas de desenvolvimento relacionadas a bancos está sob a coordenação da assistência em atendimento, assim como a centralização do atendimento dos usuários internos e externos do PJe.

[editar] Triar

A equipe de triagem da manutenção deve ser composta de, no mínimo, 3 colaboradores com perfil multidisciplinar (requisitos negociais, testes e desenvolvimento). Essa equipe deve exercer as seguintes tarefas, nessa ordem:

1. Receber a demanda do atendimento de primeiro nível.
2. Analisar e validar as informações de preenchimento da demanda.
   1. Para o caso de demandas cujo preenchimento esteja em desacordo com as instruções para abertura de demandas, deverá rejeitar a demanda e retorná-la para o atendimento de primeiro nível.
   2. Para o caso de demandas do tipo "Melhoria" ou "Nova funcionalidade", encaminhar demanda para Assistência em requisitos do PJe e capacitação.
   3. Para o caso de defeitos ou bugs em produção:
      1. Sendo a demanda aberta por um solicitante da equipe da justiça do trabalho e justiça eleitoral encaminhar para equipe pertinente.
      2. Sendo a demanda aberta por um solicitante de outro grupo (que não os citados no item anterior):
         1. Tentar reproduzir o problema no ambiente de homologação atual implantado na seção de desenvolvimento do PJe.
         2. Tentar reproduzir o problema no ambiente do tribunal (acesso à base de dados do tribunal via Infovia).
         3. Caso o problema seja confirmado em uma das tentativas de reprodução do problema, deverá certificar se o problema é de fato um comportamento esperado do sistema ou não.
            1. Para certificar-se do comportamento do sistema em relação ao problema da demanda, deve-se pesquisar a documentação publicada na wiki do PJe. Caso esse comportamento não esteja publicado na wiki, deverá acionar o líder da assistência em requisitos por meio da criação de uma demanda do tipo "Tarefa" para que essa documentação seja atualizada.
         4. Se o problema está de acordo com o comportamento esperado do sistema na versão atual, deverá orientar o tribunal sobre esse comportamento escrevendo um comentário na demanda sobre a necessidade de atualização de versão e depois fechar a demanda.
         5. Se o problema não está de acordo com o comportamento esperado do sistema e não faz parte do escopo atual, deverá orientar o tribunal para criar uma nova demanda do tipo "Melhoria" e depois rejeitar a demanda originária.
         6. Se o problema não está de acordo com o comportamento esperado do sistema e faz parte do escopo atual, deverá encaminhar a demanda para o líder da assistência em manutenção. É importante destacar que, a equipe de manutenção não deve ser represada em decorrência dos casos de falta de documentação publicada na wiki do PJe. Para esses casos, a equipe de triagem deve descrever o direcionamento da solução de forma resumida na própria demanda, e criar uma nova demanda do tipo "Tarefa" vinculada à demanda originária encaminhando para o líder da assistência em requisitos para futuro detalhamento da documentação nos padrões que o processo preconiza.
         7. Se o problema não está de acordo com o comportamento esperado do sistema e diz respeito a erros oriundos de configuração incorreta feita no sistema (exemplos: fluxos, permissão de usuário, falta de parâmetros, entre outros), deverá orientar o tribunal a respeito da configuração correta.
            1. Para certificar-se das configurações do sistema em relação ao problema da demanda, deve-se pesquisar a documentação publicada na wiki do PJe. Caso essas configurações não estejam publicadas na wiki, deverá acionar o líder da assistência em requisitos por meio da criação de uma demanda do tipo "Tarefa" para que essa documentação seja atualizada.

[editar] Homologar tecnicamente

Consiste na avaliação da codificação por parte de uma equipe centralizada, de forma que a integração do código desenvolvido à versão do PJe seja controlada.

A homologação técnica deve verificar, antes de permitir a subida do código, que todas as mudanças realizadas estejam mapeadas em comentários da demanda no JIRA. Essa exigência se deve à necessidade constante de atualização da documentação do PJe em decorrência de conclusões de melhoria assim como de correções de defeitos.

[editar] Testar

O teste do PJe hoje abrange teste manual e testes automatizados, mas são sempre funcionais. Não temos procedimentos de teste de stress ou de performance.

A execução dos testes utiliza os casos de teste definidos pela assistência em requisitos realiza seu registro no Testlink.

Para automação dos testes, o PJe se utiliza do Selenium web driver. Os casos de testes vinculados a testes automatizados devem conter referências às automações de forma a facilitar a publicidade de disponibilização da automação. Além disso, o Selenium foi integrado ao Testlink para que o resultado das execuções de teste no ambiente de automação seja refletido automaticamente no Testlink. Além disso, o JUnit é utilizado em conjunto com o Selenium para auxiliar o Selenium na verificação dos resultados esperados.

Há a pretensão de se utilizar o JMeter para testes de performance. Anteriormente, foram automatizados casos de teste funcionais com o auxílio do JMeter, prioritariamente direcionados aos testes de funcionalidades mais simples do PJe, tais como as disponíveis através do menu de configurações. Como esse não é o objetivo da ferramenta, os casos de teste serão migrados para a migração.

[editar] Liberação de versão

A assistência em atendimento, ao ser notificada da finalização de uma versão, realiza os procedimentos de geração da versão para implantação com base nos rótulos criados no GIT. A partir das versões posteriores à versão 1.4.6.4, pacotes intermediários estarão disponíveis para os tribunais com correções integradas ao código principal do PJe através da utilização de integração contínua. Disponibilizando nightly builds, ou pacotes noturnos, gerados automaticamente ao final do dia com tudo o que foi integrado pelas equipes de desenvolvimento, pretende-se facilitar e acelerar o processo de obtenção de correções por partes dos tribunais, permitindo aos tribunais testar as demandas corrigidas pelo pacote antes da liberação da versão final. Excepcionalmente, o Tribunal poderá até mesmo disponibilizar a versão “nightly” em produção caso tenha urgência na aplicação de alguma correção e considere o sistema suficientemente estável no seu escopo de utilização. É válido ressaltar que as versões nightly possivelmente não são estáveis, já que não foram realizados testes para garantir seu funcionamento. Apesar disso, as versões nightly são de grande valia para os tribunais, visto que com esse atalho, os tribunais não precisam esperar até o lançamento da versão para obtenção de uma correção prioritária para sua instalação, além de disponibilizar outras correções apontadas pelas notas de liberação da versão nightly gerada.