And all has came to this...

Sunflower

   Clytie was a water nymph, in love for Apollo, which didn’t correspond for her love, and that’s made her languish. She used to stay all day long, set on the cold floor and her braids unleashed on her shoulders. For nine days she remained, without eating or drinking, feeding only with her own tears and with the icy dew. She contemplated the sun, from the time it rose up in the spring to hide in the sunset, after its daily course; She saw nothing else, her face was constantly turning to the sun. After all, it is said, her feet rooted to the ground and her face turned into a flower, which constantly moves on its stem, so that it is always facing the sun in its daily course, thus conserving the feeling of the nymph that gave origin to the flower.

Girassol

 

Clítia era uma ninfa aquática, apaixonada por Apolo, que não lhe correspondia, o que a fez definhar. Deixava-se ficar durante todo dia sentada no frio chão, com as tranças desatadas caídas sobre os ombros. Durante nove dias assim ficou, sem comer nem beber, alimentando-se somente com as próprias lágrimas e com o gélido orvalho. Contemplava o sol, desde quando ele se erguia no nascente até se esconder no poente, depois do seu curso diário; não via outra coisa, seu rosto voltava-se constantemente para ele. Afinal, conta-se, seus pés enraizaram-se no chão e seu rosto transformou-se numa flor, que se move constantemente em seu caule, de maneira a estar sempre voltada para o sol, em seu curso diário, conservando, assim, o sentimento da ninfa que lhe deu origem.

Modularizando a Atualização de Sistema

  Um dos grandes problemas das atualizações de sistemas é o tempo de parada dos mesmos para o usuário final. Principalmente quando essa ação ocorre no Banco de Dados. Quanto maior o volume de dados e quantidade de alterações, mais tempo o sistema irá permanecer offline.

  Foi essa necessidade de diminuir esse tempo que uma empresa a qual presto consultoria de BD me trouxe. Precisávamos bolar uma estratégia de atualização de seus sistemas de modo que o usuário final ficasse o mínimo de tempo sem sistema, ou que o negócio sofresse o mínimo de impacto.

  O grande problema disso é fazer com que a versão do software corresponda a mesma estrutura do banco de dados. Claro, quando essa atualização implica em alterações de estrutura de banco como criação de tabelas, colunas, etc. Em uma atualização a quente, com os usuários utilizando o sistema, você pode até realizar as alterações necessárias no banco, dependendo também do SGBD utilizado, mas vai chegar um determinado momento, em alguma tela, que ocorrerão erros devido a estrutura divergente.

  Pensando nisso sugeri uma alteração no processo de expedição de scripts e executáveis do sistema. Mesmo sua estrutura de dados não ter sido concebida no início para ser modularizado, pensei em uma maneira de tentar modularizar a atualização, afetando apenas algumas áreas da empresa por vez. Desse modo a equipe de TI da empresa que utiliza o sistema também pode programar a parada do mesmo por módulos.

  Por exemplo, se ela tem uma área de recepção, uma área de estoque de produtos, uma área de faturamento e uma área de pesquisa e desenvolvimento eles podem planegar paradas por áreas de acordo com menor impacto ao negócio. Atualizando os módulos de recepção em um horário onde existe menor ocorrência de atendimentos, os módulos de estoque em um horário de menor movimentação de produtos, etc.

  O processo de certa forma é simples. Irá existir uma entrada que será a requisição de atualização. Nessa requisição serão preparados os scripts e executáveis correspondentes. Ai vem a mudança principal. Esses scripts tem que ser modularizados conforme os executáveis que utilizam aquela estrutura. Vai existir um conjunto de tabelas Core, que são comuns a diversos módulos. Essas precisam sofrerem o mínimo de alterações possíveis. Ao redor dessas tabelas Cores devem existir as tabelas que são utilizadas por cada módulo. Como estoque deve possuir tabelas específicas para armazenar informações relacionadas apenas a esse módulo e assim por diante. A saída desse processo serão os Logs de atualização e o produto (e base) atualizados.

  Fizemos uma atualização piloto em um dos clientes dessa empresa e, apesar de alguns pequenos problemas e ajustes iniciais, tudo correu dentro do planejado e o feedback que tivemos foi bastante positivo. Agora é amadurecer e manter o novo processo de expedição para expandir às próximas atualizações. E meu trabalho aqui está terminado!