Atualizar os fontes do ACBR trunk2 a cada quanto tempo?

[Fernando Massa]

Aqui na empresa baixamos os fontes do svn://svn.code.sf.net/p/acbr/code/trunk2 e alguns colegas defendem que devemos atualizar esses fontes diariamente e outros 1 vez por semana. O que vcs recomendam?

Estou tentando gerar uma enquete mas não sei se deu certo.

[Daniel Simoes]

As mudanças fiscais são constantes...

Os fontes do ACBr sofrem atualizações diárias....

Mas talvez seja importante você ter uma copia do Trunk2 para fazer merge com o SVN do ACBr....

E rodar seus testes unitários após o merge com as atualizações do ACBr...  

[Juliomar Marchetti]

Exato, não deve de por isso para rodar em produção, primeiro testar e depois sim. mas uma vez na semana já é tranquilo

[BigWings]

Na minha máquina de desenvolvimento eu atualizo quase diariamente.

Na máquina de build só quando noto alguma correção importante ou alguma funcionalidade nova que vou usar.

É bom sempre ficar de olho no log de alterações do SVN.

[EMBarbosa]

8 horas atrás, Fernando Massa disse:

Aqui na empresa baixamos os fontes do svn://svn.code.sf.net/p/acbr/code/trunk2 e alguns colegas defendem que devemos atualizar esses fontes diariamente e outros 1 vez por semana. O que vcs recomendam?

Estou tentando gerar uma enquete mas não sei se deu certo.

Acho que a ideia é: atualize o o mais frequente quanto possível. Mas a resposta completa vai depender da sua equipe, do tamanho da empresa e das alterações que foram disponibilizadas.

Acho que a chave é que vocês devem se sentir como desenvolvedores do ACBr. O código é também de vocês. Afinal, ele roda na sua aplicação, e afeta seus clientes. Mas esse é o meu ponto de vista particular.

Voltando a sua pergunta, por experiência própria, sugiro o seguinte:

Leiam os logs do SVN pelo menos uma vez por dia. Não é preciso atualizar para ler o log.

Ao ler o log do SVN, verifique se:

1. Alguma alteração feita afeta seus clientes em produção? (correção de bug, alteração de legislação, etc...)
2. Algum novo recurso que você quer utilizar foi implementado?
3. Se são poucas alterações e elas não são essenciais, você (ou alguém na sua equipe) tem tempo para testar?
4. São muitas alterações que foram feitas?
5. Já passou muito tempo desde que foi feita a última atualização? Por exemplo mais de 3 semanas?

Caso a resposta a qualquer pergunta acima seja "sim", atualize. No mínimo você vai estar mantendo o código do seu aplicativo com o mínimo de alterações possíveis. Então quando surgir uma situação que vocês precisem atualizar com urgência, não vai haver uma grande quantidade de trabalho acumulado.

Caso negativo, siga com as suas tarefas.

Vale lembrar também que nem toda atualização precisa de uma reinstalação. Você precisa reinstalar quando:

• As alterações envolvem partes visuais dos componentes;
• Os fontes não são recompilados ao fazer um build em sua aplicação;

Depois de atualizar, teste as partes de sua aplicação que usam os componentes modificados assim que possível. Primeiro na sua máquina de desenvolvimento, depois em outras máquinas. Por último no servidor de Build.

Faça o "deploy" de forma escalonada. Quer dizer, instale a nova versão primeiro em clientes selecionados. Escolha apenas dois, três ou no máximo quatro a princípio. Quanto mais crítica a alteração, mais seletivo você precisa ser. Depois de um tempo, envie a nova versão para os outros.

Dentre sua carteira de clientes, minha sugestão é para escolher aqueles que:

• Precisam da "novidade" apresentada no novo executável
• Tem um movimento menor (e assim darão um grau menor de dor de cabeça caso algum imprevisto aconteça)
• Ficam mais próximos de sua empresa (posso deslocar um técnico ou até mesmo um "dev" pra lá rapidamente se realmente necessário, nem que seja virtualmente?)
• São mais pacientes e compreensivos (paciência nunca é demais, apenas cuide de não abusar deles)

Nota: É claro que, se vocês estão no meio de uma situação que precisa que todo o desenvolvimento fique focado no produto de vocês, talvez não seja possível atualizar o ACBr. Por exemplo, pode ser que um problema no software esteja exigindo a atenção urgente de toda equipe. Mas geralmente, pelo menos um dev deve conseguir dar uma lida nos logs e fazer a avaliação se é necessário ou não atualizar.

[Fernando Massa]

Estou gostando do resultado, também as respostas do EMBarbosa bem ponderada, mas claro, a ideia aqui seria sempre pensando na versão que está no cliente. Em certo momento ocorreu de ser gerada uma versão quase todo dia porque tinha alterações no ACBR, mas eu sou da opinião que se não deu problema no cliente, e tudo está fluindo bem, da pra esperar uma semana. até porque vejo que a equipe do ACBR não trabalha com os prazos esgoelados. E estas questões da receita sempre tem um prazo generoso de adaptação.

Resumindo. Não vai deixar de funcionar nada no cliente por causa de alterações que ocorreram no ACBR, se são muitas ou poucas, se é arquivo de danfe.fr3 (por causa de alguma alteração) ou se são arquivos de "Schemas" novos. Essas alterações não vão ter impacto, imediato no cliente. Não à motivo para ficar desesperado.

Se colocar essas atualizações 1 vez por semana no cliente, está bem de boa.

[Juliomar Marchetti]

Gerar versões do sistema deve ser programada e somente deve ser feito versões sem planejamento quando ocorre algo inesperado, por exemplo sefaz mudou endereço do dia pra noite.

senão versão tem data de lançamento.

[EMBarbosa]

1 hora atrás, Fernando Massa disse:

Em certo momento ocorreu de ser gerada uma versão quase todo dia porque tinha alterações no ACBR, mas eu sou da opinião que se não deu problema no cliente, e tudo está fluindo bem, da pra esperar uma semana. até porque vejo que a equipe do ACBR não trabalha com os prazos esgoelados. E estas questões da receita sempre tem um prazo generoso de adaptação.

Nesse caso, precisamos entender melhor o que você e sua equipe estão discutindo.

O que vocês estão discutindo? Vocês estão discutindo a atualização do ACBr ou o "deploy", que é o envido de versões aos clientes?

Vocês precisam de uma estratégia de "desenvolvimento" e uma estratégia de deploy. Tudo bem que as duas estratégias podem ser interligadas, como é o caso quando se usa um sistema de "Implantação Contínua". Mas são duas coisas bem diferentes.

1 hora atrás, Fernando Massa disse:

Resumindo. Não vai deixar de funcionar nada no cliente por causa de alterações que ocorreram no ACBR, se são muitas ou poucas, se é arquivo de danfe.fr3 (por causa de alguma alteração) ou se são arquivos de "Schemas" novos. Essas alterações não vão ter impacto, imediato no cliente. Não à motivo para ficar desesperado.

Se colocar essas atualizações 1 vez por semana no cliente, está bem de boa.

Não vou dizer que você está errado nas sua posição. Porque não está. Na verdade, talvez não tenha certo ou errado aqui. E claro, ninguém deveria ficar desesperado para instalar uma nova versão sem fazer testes. Também, antes de enviar uma versão aos clientes é preciso levar em conta a quantidade de clientes, o tamanho da equipe de desenvolvimento e suporte e até o plano de negócios da empresa.

Por outro lado, acho que as seguintes perguntas precisam também ser analisadas: Só se envia uma nova versão ao cliente para resolver problemas? Não são apresentadas ao cliente os novos recursos como algo que facilita a vida dele? Não seria muito mais interessante comercialmente se o programa tivesse sempre novidades para cativar o usuário? Não será muito mais difícil encontrar e resolver um problema se de uma versão para outra houverem muitas alterações no código? Que controle se faz de versão do software que está instalado no cliente? Consegue-se facilmente reproduzir no ambiente de desenvolvimento?

Vou deixar esse link de artigo aqui que eu achei muito interessante de um pessoal que saiu do "GitFlow" e foi pro "Trunk Based Development". Leia também os comentários onde alguns categoricamente não concordam. É um artigo pra pensar no desenvolvimento.

https://www.gamasutra.com/blogs/NiklasGray/20170927/306445/Moving_away_from_GitFlow.php

Enfim, eu disse implicitamente antes, mas agora vou falar explicitamente.

Não estou dizendo que uma maneira é melhor do que a outra. Cada empresa precisa pesar as vantagens e desvantagens e decidir o que é melhor para empresa, sua equipe e seus clientes. Não leve em conta só a sua equipe. Mas também, não leve em conta só os clientes. Isso poderia fazer sua equipe sofrer.

 

[Fernando Massa]

5 horas atrás, EMBarbosa disse:

Nesse caso, precisamos entender melhor o que você e sua equipe estão discutindo.

O que vocês estão discutindo? Vocês estão discutindo a atualização do ACBr ou o "deploy", que é o envido de versões aos clientes?

Vocês precisam de uma estratégia de "desenvolvimento" e uma estratégia de deploy. Tudo bem que as duas estratégias podem ser interligadas, como é o caso quando se usa um sistema de "Implantação Contínua". Mas são duas coisas bem diferentes.

Não vou dizer que você está errado nas sua posição. Porque não está. Na verdade, talvez não tenha certo ou errado aqui. E claro, ninguém deveria ficar desesperado para instalar uma nova versão sem fazer testes. Também, antes de enviar uma versão aos clientes é preciso levar em conta a quantidade de clientes, o tamanho da equipe de desenvolvimento e suporte e até o plano de negócios da empresa. .................

Amigo, vou imprimir o que vc escreveu acima e emoldurar pra colocar aqui na empresa. Pois isso que vc falou é o que a galera "do meu lado" está tentando fazer, mas a empresa tem uma cultura muito diferente e mesmo sendo evidente que isso prejudica, está difícil de mudar.

Imaginem só.... Já ocorreu (a um ano atrás) de ter que atualizar vários clientes, mais de uma vez, num único dia. Por falta de testes nas alterações do sistema. Em fim, agora já melhorou muito, isso mas ainda temos um caminho a trilhar para que todos entendam que liberar uma versão para o cliente é algo sério que está diretamente relacionado com a reputação da empresa.

[EMBarbosa]

16 horas atrás, Fernando Massa disse:

Amigo, vou imprimir o que vc escreveu acima e emoldurar pra colocar aqui na empresa.

Mas não esqueça do que eu escrevi no final.

22 horas atrás, EMBarbosa disse:

Não estou dizendo que uma maneira é melhor do que a outra. Cada empresa precisa pesar as vantagens e desvantagens e decidir o que é melhor para empresa, sua equipe e seus clientes. Não leve em conta só a sua equipe. Mas também, não leve em conta só os clientes. Isso poderia fazer sua equipe sofrer.

Se não teve tempo, sugiro ler o artigo que eu citei.

[EMBarbosa]

Baseado nessa discussão, criamos um tópico na nossa base de conhecimentos sobre o assunto. Vejam: