Ir para conteúdo


Foto
- - - - -

Função para atualização do programa

atualização

  • Por favor, faça o login para responder
12 respostas neste tópico

#1 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 21 janeiro 2016 - 04:30

Boa tarde.

 

Sempre achei muito interessante a possibilidade de atualizar os programas automaticamente.

Na maioria das vezes, ter que passar cliente por cliente atualizando um programa é totalmente anti-prático.

E dependendo do caso, leva um tempo considerável e até mesmo as despesas de deslocamento/hospedagem torna o processo muito custoso.

 

Com o uso da internet e suporte remoto, facilitou consideravelmente, mesmo assim a atualização ainda depende de conectar no cliente, interrompê-lo por um tempo ou programar o atendimento, etc etc.. Então supondo que o programa se atualize quando é ativado pela primeira vez no dia, facilita para todo mundo.

 

Mesmo assim, atualizar um programa não é uma tarefa fácil, pois além da estrutura necessária (servidor, espaço em disco, internet...) ainda tem a dificuldade adicional de substituir um programa que está em execução e finalmente a possibilidade de incluir essa "função" no programa de modo razoavelmente simples.
 

Claro que qualquer atualização mal projetada pode dar muito mais dor-de-cabeça do que ajudar, portanto muito cuidado ao lançar atualizações!

 

Depois de algum tempo trabalhando com essa idéia, muitos testes e métodos depois, acredito que a tenha deixado suficiente madura e testada para compartilhá-la, a ponto de ser facilmente utilizada.

 

O princípio é simples:

  1. você já tem um programa em execução e quer poder atualizá-lo
  2. ao ser executado, o programa verifica se há uma conexão de internet
  3. se existe a conexão, verifica a disponibilidade de uma nova versão
  4. se há a nova versão, baixa a nova versão e substitui a atual (mais velha) pela nova
  5. para o cliente, este processo ocorre de forma automática e ele nem percebe, pois não há interação com ele

 

Não é uma rotina/função definitiva, pois cada caso é um caso. Também estudei várias maneiras de substituir o programa em execução e optei pela mais funcional para mim.

 

Por fim, como não é apenas uma função que possa ser inserida no programa, visto que tem algumas peculiaridades, fiz o contrário, desenvolvi uma rotina e é mais fácil inserir SEU programa dentro dela. Talvez alguém consiga transformar realmente numa função!

 

Características a serem observadas:

  • totalmente em AutoIt (não é necessário nenhuma biblioteca ou programa extra).
  • para verificação de uma versão nova, utilizo algoritmo MD5. Se o MD5 do programa atual for diferente do que está na internet, baixa a versão nova. Dessa forma também é possível fazer tanto UPGRADE como DOWNGRADE de versões.
  • para disponibilizar a atualização corretamente, é necessário ter o programa principal (versão nova) E o arquivo MD5 associado (ver exemplo abaixo).
  • para criar o arquivo MD5, segue rotina em separado que deve ser executada após a compilação definitiva do programa principal.
  • se não existir arquivo .MD5 (tem opção - DESATIVADA por padrão - de forçar download do programa principal) ou se não existir arquivo nenhum (nem MD5 nem principal), ignora a atualização.
  • para programas (.EXE) e para biliotecas (.DLL) existe a opção (ATIVADA por padrão) de verificação da versão adequada para 64 bits.
  • após o download, verifica se este foi completado com sucesso de acordo com o próprio MD5, para evitar problemas no download.
  • se por qualquer motivo o download não foi completado ou corrompeu a versão nova ou quaisquer erros, PERMANECE a versão anterior (não quebra o cliente).
  • em ambientes 64 bits, facilita a instalação, pois se baixar a versão 32 bits, esta vai baixar a versão correta e substituir.

 

Enfim, até ser colocada uma versão nova no servidor, não existe obrigatoriamente a necessidade de existir nenhum arquivo no servidor. Assim o programador decide quando haverão atualizações.

 

  • a verificação de parâmetros é muito específica, dessa forma não atrapalha eventuais outros parâmetros que sejam passados ao programa principal.
  • obviamente NÃO É possível testar a rotina executando-a diretamente do editor (SciTE). Mesmo assim, não faz nada se executada no editor para não atrapalhar o desenvolvimento do programa principal
  • acompanham os ícones que utilizo para mostrar no Systray a evolução do download.

 

MUITO IMPORTANTE

  • a variável $Versao é somente para fins decorativos (não tem efeito prático na rotina).
  • ao informar o nome do programa na variável $Nome_Soft, qualquer alteração do nome, fará com que o programa seja renomeado para $Nome_Soft.
  • se informado também o caminho completo na variável $Programa, então o programa se auto-instala na pasta informada.
  • no caso de existir uma pasta específica, demais arquivos que precisem ser copiados/movidos são de responsabilidade do programador.
 

Para fins de exemplo, o nome dos arquivos a serem colocados no servidor ficariam assim:

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido

Finalmente a chamada à função fica logo no início do seu programa principal:

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido

Tomara que seja útil para vocês como está sendo para mim.

Fiquem à vontade para modificá-la para adequação aos seus propósitos.

Estou a disposição para eventuais correções e/ou melhorias.

Arquivo(s) anexado(s)


Editado por Manimal, 23 fevereiro 2016 - 07:46 .


#2 mutleey

mutleey

    AutoIt MVP

  • AutoIt MVPs (MVP)
  • PipPipPip
  • 277 posts
  • LocationSão José do Rio Preto-SP

Postado 22 janeiro 2016 - 10:12

Manimal muito boa sua ideia, e parabéns por compartilhar... os softwares que desenvolvi faço atualizações por controle remoto e esta ideia sua vai ser muito util!



#3 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 22 janeiro 2016 - 01:38

@mutleey

Obrigado  :like_icon:

Faça bom proveito!



#4 marcio

marcio

    Membro

  • Membros
  • Pip
  • 52 posts

Postado 20 fevereiro 2016 - 05:08

Manimal,

 

Obrigado por compartilhar!!!

 

Será que o seu script pode ser adaptado para verificar e atualizar através da rede, tipo: "\\Servidor\Caminho\Executável" ???

 

Abraços.

 

Márcio.


Editado por marcio, 20 fevereiro 2016 - 05:09 .


#5 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 21 fevereiro 2016 - 07:06

Olá Márcio.

 

Não entendi. Vc tem uma rede e em cada terminal vc tem um executável, isso?

E daí pretende atualizar os programas a partir de uma máquina base (servidor)?



#6 Frezan

Frezan

    Membro

  • Membros
  • Pip
  • 63 posts
  • Location

Postado 21 fevereiro 2016 - 04:07

Bacana Manimal. No caso, a própria aplicação iria checar e atualizar para uma nova versão?

 

Por ser uma UDF, tu poderias encapsular ela e para que o código do programa em si fique mais limpo. Exemplo:

 

[AtualizacaoUDF.au3]

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido

[Programa.au3]

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido



#7 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 22 fevereiro 2016 - 09:59

@Frezan

 

A idéia é essa, do programa procurar sua própria atualização e se houver, atualizar-se.

 

Em relação ao encapsulamento: Excelente sugestão, muito bem pensado! Não tinha visto por esse ângulo.

 

Então nessa linha de pensamento, poderíamos fazer as seguintes mudanças:

 

1) para não precisar mudar a UDF constantemente (pois assim não seria uma UDF) as variáveis $Versao e $Nome_Soft DEVEM ser movidas para o programa principal, desta forma o encapsulamento fica completo

 

2) a variável $Meu_Site não deve mudar com frequência pois, na teoria, os programa sempre seriam baixados no site do desenvolvedor, mas se precisar personalizar para cada programa, sugiro que ela seja movida também para o programa principal, senão pode ficar dentro da função, porém é NECESSÁRIO que seja ajustada pelo menos a primeira vez

 
3) as demais variáveis "globais" pode ser movidas para suas respectivas funções, sendo:

   - a variável $PID_Pai pode ser local na função START_ATUALIZACAO()

   - as variáveis $TRAYICON_PADRAO e $TRAYICON_DOWNLOAD para a função BAIXA_ARQ()

   - as variáveis $Programa e $Temp_Programa podem ser locais na função PROG_ATUALIZADO()

 

Aproveitei e fiz mudanças na função ESTA_RODANDO, porque descobri situações em que não estava funcionando a contento.

 

Finalmente, usando o teu exemplo, o programa ATUALIZACAOUDF.AU3 ficaria assim:

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido

e depois no programa principal

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido

Obrigado por participar  :600866:



#8 Frezan

Frezan

    Membro

  • Membros
  • Pip
  • 63 posts
  • Location

Postado 22 fevereiro 2016 - 01:15

Não esqueça de atualizar os arquivos ali em cima. Abraço :mc-hammer:



#9 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 23 fevereiro 2016 - 07:47

Arquivos atualizados.

Obrigado pela dica! :like_icon:



#10 marcio

marcio

    Membro

  • Membros
  • Pip
  • 52 posts

Postado 02 março 2016 - 11:41

Olá Márcio.

 

Não entendi. Vc tem uma rede e em cada terminal vc tem um executável, isso?

E daí pretende atualizar os programas a partir de uma máquina base (servidor)?

 

 

Caro Manimal.

 

Isso mesmo!

 

Cada máquina ao executar o .EXE verifica se há no servidor um .EXE com a versão superior à do .EXE que esta em execução na máquina, se for superior, fecha imediatamente o .EXE que esta em execução e o substitui pelo .EXE do servidor e o executa automaticamente.

 

Encontrei um exemplo aqui no fórum:

Por favor Login ou se não possuir um conta Registre-se para ver o conteúdo escondido

 

...mas eu gostaria de saber se o seu script poderia ser adaptado.

 

* Desculpe-me pela demora em responder.

 

Obrigado.

 

Márcio.


Editado por marcio, 02 março 2016 - 11:51 .


#11 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 03 março 2016 - 02:55

Olá Márcio.

 

Não vejo muita dificuldade em modificar a função para implementar a atualização em rede, mas estou intrigado pela sua situação.

 

Posso perguntar o porque de vc ter vários executáveis separados em uma mesma rede? A única situação que consigo ver é uma questão fiscal num supermercado, por exemplo, onde a legislação exige que o caixa seja independente pois se houver falta de luz e o servidor não puder ser contatado, o caixa deve permanecer operando em modo "bateria" até a luz voltar (ou a bateria acabar...)

 

Não seria mais interessante simplesmente fazer um atalho para o executável diretamente do servidor?

 

E mesmo que houvesse alguma razão para manter as cópias separadas, a atualização através da rede seria apenas para minimizar o download das versões novas?

 

Obrigado.



#12 marcio

marcio

    Membro

  • Membros
  • Pip
  • 52 posts

Postado 03 março 2016 - 09:04

Caro Manimal.

 

É que por medida de segurança, não é permitido gravar arquivos executáveis nos servidores, então eu normalmente envio através do e-mail um link para os usuários que dá acesso a uma pasta previamente compartilhada que copia o .EXE atualizado para a Área de Trabalho de cada um.

 

Obrigado.

 

Abraços.

 

Márcio.



#13 Manimal

Manimal

    Membro Nível 3

  • Administradores (Adm)
  • PipPipPipPip
  • 319 posts
  • LocationVideira/SC

Postado 04 março 2016 - 09:52

Olá Márcio.

 

Entendi. Desta forma vc previne que executáveis sejam colocados no servidor, teoricamente deixando-o mais seguro, porém com o preço de ter vários "executáveis" espalhados pela rede e acessando apenas os dados, isso?

 

Assim, por conta desta situação, existe a necessidade de atualização desses executáveis "espalhados".

 

Em relação à rotina de atualização, acredito que não seja problema de adaptar, como já tinha comentado antes, mas ainda fica uma última dúvida minha. Porque não permitir a atualização online via internet? É por causa da necessidade de acesso externo ou pela necessidade de estrutura de armazenamento (página remota, espaço, etc...)?

 

Neste último caso, nem sempre é viável ou vantajoso para a empresa montar esta estrutura só para atualizar os programas.

 

Obrigado.


Editado por Manimal, 04 março 2016 - 09:52 .






Tópicos que também usam as tags atualização:

0 usuário(s) está(ão) lendo este tópico

0 membro(s), 0 visitante(s) e 0 membros anônimo(s)

Documentação OnLine de referência