Uma checklist de promoção de objetos JD Edwards EnterpriseOne para ambientes DV, PY e PD é o documento de processo que separa instalações onde a produção permanece tranquila de instalações onde toda terça-feira de manhã parece uma emergência. A diferença quase nunca está no talento dos desenvolvedores. A diferença está em saber se todos concordam sobre o que precisa ser verdadeiro antes que um objeto possa passar de um ambiente para o outro, e se alguém verifica cada item antes que o status OMW seja alterado.

Já encontrei ambientes JDE em que o processo de promoção era “pergunte ao Marco se está pronto” e outros em que havia uma checklist de trinta itens impressa na parede acima da mesa do CNC. O segundo tipo de organização tem menos interrupções, recuperações mais rápidas e desenvolvedores que não temem os deployments de segunda-feira. A checklist em si não é mágica. O valor está no fato de que todos — desenvolvedor, líder técnico, equipe CNC e responsável de negócio — sabem o que será verificado antes que a mudança chegue ao PD.

Para que DV, PY e PD realmente existem

O modelo de três ambientes no JDE E1 parece igual em qualquer instalação, mas significa algo ligeiramente diferente em cada uma. DV, desenvolvimento, é onde vive o código instável — código que pode não compilar, quebrar o formulário que toca ou corromper dados de teste. O único compromisso do DV é que tudo o que existe ali pertence a um desenvolvedor capaz de corrigir. PYAmbiente Prototype ou Pristine — a camada de teste JDE onde o código promovido é executado contra uma cópia de dados próxima da produção antes de ser movido para PD. O “Y” vem do antigo path code Pristine/Pristine-Yes. é onde vive o código estável que passou por revisão de pares, testado contra dados suficientemente parecidos com os de produção para revelar erros que o DV nunca mostraria. PD é produção: o ambiente onde o negócio roda, com compromisso de disponibilidade e correção.

O erro que vejo com mais frequência é tratar PY como “DV com dados melhores”. Não é. PY é um ambiente de release candidate, e o código em PY já passou por um gate. Se três desenvolvedores estão enviando trabalho inacabado para PY porque “é só o ambiente de teste”, então o gate real foi deslocado para entre PY e PD, e PY deixou de cumprir sua função. A equipe de testes funcionais começa a encontrar erros que deveriam ter sido capturados em DV, os ciclos de regressão aumentam, e a cadência de promoção para PD cai de semanal para mensal.

Cada ambiente vive em seu próprio path code — DV920, PY920, PD920 em uma instalação 9.2, com as respectivas tabelas de business data em ambientes como DV920FA, PY920FA e PD920FA. A checklist abaixo assume esse mapeamento. Se a sua instalação usa nomes não padrão, substitua-os, mas os gates e a ordem permanecem os mesmos.

O gate de DV para PY: o que precisa ser verdadeiro antes que o código deixe as mãos do desenvolvedor

O primeiro gate de promoção é onde está a maior parte do valor, porque erros encontrados aqui custam minutos, enquanto os mesmos erros encontrados no gate de PY para PD podem custar dias. Antes que qualquer objeto seja movido de DV para PY por meio de uma alteração de status no OMWObject Management Workbench — a ferramenta JDE que gerencia check-in, check-out, associação a projetos e transições de status entre path codes DV, PY e PD., a checklist desse gate inclui aproximadamente seis itens.

O objeto deve compilar corretamente em DV. Para BSFNs e table conversions, isso não é negociável, e o log de build deve mostrar zero erros e zero warnings. Os warnings importam: em BSFNs C, eles viram falhas em runtime com muito mais frequência do que os desenvolvedores gostam de admitir. O spec merge contra a baseline ESU padrão mais recente deve ser revisado, especialmente em objetos de retrofit, onde o padrão pode ter mudado desde o último refresh feito pelo desenvolvedor. A data structure usada pela função ou aplicação deve ser verificada contra os pontos de chamada. Um novo campo adicionado a uma DS pode quebrar todo caller que não foi recompilado, e a ordem de recompilação faz parte do plano de promoção, não é um detalhe posterior.

O projeto OMW deve conter todos os objetos tocados, não apenas o objeto principal: o formulário que chama a nova BSFN, a data structure usada pela BSFN, a tabela UDC lida pelo novo código e as linhas F7900 adicionadas para os novos códigos de erro. Um projeto que promove a BSFN mas esquece a nova linha F7900 falhará em runtime em PY com uma mensagem de erro vazia, que pode tomar uma hora do engenheiro de plantão para rastrear.

A revisão por pares é o gate humano que identifica o que as ferramentas não conseguem detectar. Um segundo desenvolvedor lendo a mudança, mesmo por dez minutos, muitas vezes encontra a suposição que o desenvolvedor original não percebeu: o número da companhia fixo no código, a comparação de datas que quebra na virada do ano ou a busca que retorna a primeira linha quando deveria agregar. O status 25 no OMW é a convenção para “revisado por pares e pronto para promover”. Essa convenção só funciona se todos os desenvolvedores a respeitam.

O gate de PY para PD: onde o risco de negócio é realmente gerenciado

O segundo gate é onde a checklist de promoção prova seu valor. O código que passou de DV para PY está tecnicamente correto de forma isolada. Para passar de PY para PD, ele precisa funcionar junto com tudo o que já existe em produção, e o próprio deployment não pode quebrar o negócio.

O primeiro item desse gate é a aprovação dos testes. Quem é responsável pelo processo de negócio afetado — entrada de pedidos, faturamento, folha de pagamento ou reposição de estoque — deve ter confirmado pessoalmente que o comportamento em PY corresponde ao esperado. Não “a equipe de desenvolvimento acha que funciona”, mas o responsável de negócio que receberá os chamados de suporte se algo der errado. Sem essa aprovação, o desenvolvedor é a única pessoa que realmente tocou no código, e também será a única pessoa culpada quando ele quebrar.

O plano de build do package deve estar explícito antes que o gate seja aberto. Update package, foundation package ou full package? Um update é suficiente para mudanças em ER e formulários. Foundation é obrigatório sempre que código C BSFN compilado foi alterado — e “obrigatório” significa restart de servidor, portanto uma janela de indisponibilidade coordenada. Um full package deve ser reservado para mudanças de Tools Release e deployments cumulativos trimestrais. Escolher o tipo de package errado ou não entrega a mudança — update sem foundation quando C foi alterado — ou causa uma interrupção desnecessária ao negócio, quando um update teria sido suficiente.

O plano de rollback deve ser escrito antes que a mudança seja promovida, não depois que o alarme dispara. Para mudanças em ER, o rollback é um restore da versão anterior do objeto via OMW. Para mudanças em C BSFN, o rollback é uma nova promoção do foundation package anterior, que pode levar os mesmos 30 a 60 minutos da instalação original. Para mudanças de Data Dictionary que afetam muitos formulários, pode não existir um rollback limpo. Esse tipo de informação precisa estar na checklist do gate, não ser descoberto às 02:00 quando algo quebra.

Verificações de coexistência: quando o novo objeto encontra o restante do PD

O risco oculto em uma promoção raramente está no novo objeto em si. Ele está na interação entre o novo objeto e as dezenas de objetos standard e custom que já existem em PD. A checklist precisa de uma verificação explícita para essas interações, porque nada mais as detectará de forma confiável.

O estado do spec merge é a primeira verificação de coexistência. Se o novo objeto herda de um objeto standard que mudou entre o início do desenvolvimento e a promoção programada, o spec merge deve ser executado novamente, o diff revisado e cada conflito resolvido. Ignorar esse passo é como uma customização de P4210 que funcionava perfeitamente na 9.2.6 deixa de funcionar quando a instalação aplica o cumulativo 9.2.8 — porque o formulário standard se moveu por baixo da customização.

As dependências de chamadas BSFN são a segunda verificação. Uma nova BSFN que chama BSFNs existentes exige que essas funções chamadas sejam verificadas em PD na versão contra a qual o novo código foi testado. Um novo campo adicionado a uma data structure existente significa que todo caller no projeto OMW precisa estar na mesma promoção — e qualquer caller fora do projeto precisa ser identificado, testado em regressão e incluído no pacote ou explicitamente liberado como não afetado.

Adições de UDC e Data Dictionary são a terceira verificação. Novos valores UDC para um tipo UDC existente normalmente são seguros. Novos tipos UDC referenciados por código não são, porque o tipo precisa existir na F0004 em PD antes que o código que o lê seja executado. O item da checklist aqui é: “verificar se cada nova linha F0004 e F0005 exigida pelo package existe em PD antes que o código dependente seja promovido”. Dois minutos de verificação prévia evitam horas de suporte.

O que acontece no momento da promoção para PD

O ato da promoção em si é a etapa mais procedural de toda a sequência, e exatamente por isso é a etapa em que decisões improvisadas causam mais danos. Uma promoção para PD é um evento programado, não uma operação do tipo “vamos fazer agora enquanto está calmo”.

A janela é anunciada com antecedência — para a equipe de operações, para os responsáveis de negócio e para qualquer pessoa cujos batch jobs rodem durante esse período. A equipe CNC é responsável pela transferência OMW e pelo build do package. Desenvolvedores não promovem seu próprio código para PD em nenhuma instalação com segregação de funções adequada, tanto por exigências de auditoria quanto porque a pessoa que escreveu o código é a pior pessoa para validar que ele funciona em um ambiente limpo.

A verificação pós-promoção é o último item da checklist e o mais frequentemente ignorado. Dentro da mesma janela de manutenção, um smoke test é executado contra a mudança promovida — uma transação com formato realista pelo caminho afetado, de ponta a ponta, contra dados de PD usando uma conta de teste identificada. Essa verificação prova que o package foi construído, implantado e está chamável. Sem esse passo, a primeira vez que o novo código roda em PD é quando um usuário real o aciona na manhã útil seguinte, e qualquer problema de deployment vira um incidente de produção em vez de um rollback dentro da janela de manutenção.

Para mais detalhes sobre o lado operacional do trabalho em JDE, os artigos relacionados sobre estratégia de upgrade de Tools Release, retrofit de cópias de objetos standard e harnesses de teste para BSFN cobrem o contexto ao redor. O portfólio técnico deste site documenta dois deployments em produção que deram origem aos padrões de checklist descritos aqui.