Expedição1. Expedição
Este tópico tem como objetivo detalhar a expedição do TAF, tanto no processo de manutenção quanto no processo de inovação.
1.1. Particularidades no
macro processo de inovação
:1a. Durante o ciclo de construção, os chamados de Legislação ( SSIM ) e os requisitos de Inovação ( JIRA ) serão desenvolvidos e homologados na branch de Inovação;
Branch de Inovação do TAF - versão11: $/TAF/Inovação
Image Added Branch de Inovação do TAF - versão 12 ( release incremental ): $/Protheus_Padrao/Fontes_Doc/Inovação/V12
Image Added b2. As alterações de fontes, tabelas autocontidas e layout de integração deverão ser realizadas nos diretórios de Inovação;
3c. As alterações de dicionário deverão ser realizadas no ATUSX ( em pacote individual ) e incorporados no final do release de expedição;
4d. Os pacotes do ATUSX sempre devem ser criados abaixo do Projeto do Release de entrega da versão 12;
5e. Assim que o chamado/requisito for homologado na versão 11, deve ser solicitado ao GCAD que faça a incorporação no Projeto TAF Segregado ( utilizado para atualização do TAF na versão 11 );
6f. Assim que o chamado/requisito for homologado na versão 12, este automaticamente será incorporado ao Release “pai” para expedição.
7g. Os requisitos/chamados da versão 11 devem obedecer o Calendário do TAF;
8h. Os requisitos/chamados da versão 12 devem obedecer o Calendário do Release Incremental.
1.2. Particularidades
no macro processo de manutenção
:1. Durante o ciclo de construção, os chamados de Não Conformidade serão desenvolvidos e homologados na branch de manutenção.
2. Quando chamado na versão 11, as alterações de dicionário deverão ser realizadas no UPDTAF quando não contemplado pelo UPDDISTR*.
*Detalhes sobre as regras do UPDDISTR:
Fluxo operacional:
Manutenção
( devido as mudanças no processo do release incremental este tópico está sendo reavaliado )
Os códigos fontes do TAF estão armazenados em um único diretório no TFS. Qualquer manutenção nas rotinas, independente da versão do TAF ( 11 ou 12 ), devem ser realizadas nesse único diretório.
Após a homologação do chamado, as alterações serão compiladas em 4 diretórios distintos:
1) D-1 Protheus Padrão - Versão 11 ( todas as línguas e bases );
2) D-1 Protheus Padrão - Versão 12 ( todas as línguas e bases );
3) D-1 TAF - Versão 11 ( todas as línguas, base TOPCONNECT );
4) D-1 TAF - Versão 12 ( todas as línguas, base TOPCONNECT ).
Todo chamado da versão 11 deverá gerar uma réplica para a versão 12. Como o fonte já foi corrigido na versão 11 e este se aplica à todas as versões, a FNC réplica da versão 12 deverá ser encerrada apenas com os fontes corrigidos amarrados como dependência no pacote. Deverá ser colocada uma observação no encerramento da FNC, indicando o chamado original que aquele erro já foi corrigido.
Versão | 12 |
---|
1 - Chamado envolve alteração de dicionário | - Fonte: Alterar na branch de Inovação do Release Corrente
- Dicionário: Alterar apenas no ATUSX - Pacote MANUTENÇÃO do Release corrente
|
---|
2 - Chamado não envolve alteração de dicionário | - Fonte: Alterar na branch de Manutenção
|
---|
3 - Chamado envolve alteração de tabela autocontida | - Tabela Autocontida: Alterar na branch de Inovação do release corrente
- Regra: A tabela autocontida sofrerá manutenção através de uma legislação, e consequentemente entrará no processo de inovação ( item 1 ).
- Exceções ( apenas em casos críticos ): Alterar na branch de manutenção com uma sub-versão, exemplo: autocontidasv100301.taf.
- Devem ser alterada a versão apenas dos .dbf que sofreram manutenção. Os demais mantem a versão.
|
---|
4 - Chamado envolve alteração no layout.def / dbf / dtc | - Layout: Alterar na branch de Inovação do release corrente
- Regra: O Layout sofrerá manutenção através de uma legislação, e consequentemente entrará no
processo de inovação ( item 1 ). - Exceções ( erros ): Criar uma sub-versão na seção de "build" do layout dentro do layout.def
- Observação: Criar uma seção de versão dentro do layout.def ( formato: versão + sub-versão + data ) exemplo: 2.600120150626
- Criptografar arquivo layout.def ( + interface que descriptografa o arquivo para visualização )
|
---|
Versão | 11 |
---|
1 - Chamado envolve alteração de dicionário | - Fonte: Alterar na branch de manutenção
- Dicionário: Alterar o UPDTAF ( UPDDISTR não executa o RUP_ na versão 11 )
- Observação: Alterar o manual de atualização orientando a execução do UPDTAF que primeiro executa o UPDDISTR (automático) e depois o UPDTAF.
- Documentar todas as alterações no boletim ( TDN ).
- Criar uma trava no UPDATE, só pode ser executado na versão 11 ( quando o diretório único estiver em produção ) verificar o nome da função genérica.
|
---|
2 - Chamado não envolve alteração de dicionário | - Fonte: Alterar na branch de Manutenção
|
---|
3 - Chamado envolve alteração de tabela autocontida | - Tabela Autocontida: Alterar na branch de Inovação do release corrente
- Regra: A tabela autocontida sofrerá manutenção através de uma legislação, e consequentemente entrará no processo
de inovação ( item 1 ). - Exceções ( apenas em casos críticos ): Alterar na branch de manutenção com uma sub-versão, exemplo: autocontidasv100301.taf.
- Devem ser alterada a versão apenas dos .dbf que sofreram manutenção. Os demais mantem a versão.
|
---|
4 - Chamado envolve alteração no layout.def / dbf / dtc | - Layout: Alterar na branch de Inovação do release corrente
- Regra: O Layout sofrerá manutenção através de uma legislação, e consequentemente entrará no
processo de inovação ( item 1 ). - Exceções ( erros ): Criar uma sub-versão na seção de "build" do layout dentro do layout.def
- Observação: Criar uma seção de versão dentro do layout.def ( formato: versão + sub-versão + data ) exemplo: 2.600120150626
- Criptografar arquivo layout.def ( + interface que descriptografa o arquivo para visualização )
|
---|
Alterando o dicionário