lunes, 17 de agosto de 2015

[3 de 97]. Controlar os dados, não só ao código.

“Control the data, no just the code.”




Eli diz (extraído do livro  "97 things Every Software Architech Should Know"):


---
Control de data, no just de code.
Source code control and continuous integration are excellent tools for managing the application build and deployment process. Along with source code, schema and data changes are often a significant part of this process and thus warrant similar controls. If your build and deployment process includes a list of elaborate steps required for data updates, beware.


....


Database changes shouldn’t create a ripple in your build’s time-space continuum. You need to be able to build the entire application, including the database, as one unit. Make data and schema management a seamless part of your automated build and testing process early on and include an undo button; it will pay large dividends. At best it will save hours of painful, high-stress problem solving after a late night blunder. At worst it will give your team the ability to confidently charge forward with refactoring of the data access layer.
---


Eu acho que antes a gente  não dava muita importância ao banco de dados (a partir da nossa  perspectiva de desenvolvedor), porque era uma tarefa, no melhor dos casos entediante, e na pior das hipóteses muito complexa para explicar aos clientes.


Mas à medida que nós participamos em projetos, descobrimos que o sucesso desses projetos começa com uma boa definição da camada de dados.


Também, conforme têm evoluído as metodologias e técnicas para o desenvolvimento e integração dos aplicativos, e com o advento dos métodos ágeis, eu acho que chegou a hora de dar aos bancos de dados o seu devido lugar na foto.


Um dos meus piores pesadelos sempre foi o de atualizar  uma tabela (parâmetro) e ao fazer COMMIT perceber que eu esqueci a cláusula WHERE,
Uma catástrofe !!!


Felizmente, ter um script para preencher inicialmente as tabelas de configuração sempre dão a tranquilidade de saber que você pode voltar ao último “estado correto”.


E esses scripts não estão sozinhos, temos também scripts para:
  • Criar / Apagar tabelas.
  • Criar / Apagar procedimentos armazenados (store procedures).
  • Criar / Apagar sequências
  • etc, etc.


E há um tipo de script que sempre fica no esquecimento: os scripts de migração ou de backup do banco de dados.


Se você ainda não esteve em uma conferência por telefone onde todo mundo está à beira da histeria, porque ninguém sabe o que faltou ao migrar para a nova e brilhante base de dados recém adquirida (por muitos milhares em $), leve sempre em conta a seguinte pergunta:


>>> Cara,  será que você não se esqueceu de migrar os store-procedure e  os triggers?


Se isso realmente acontecer, haverá um grande silêncio.
E o gerente de plantão dirá:
>>> Bem, vamos rever isso e, em seguida, a gente te liga.


Essa ligação nunca chega ;)


Enfim de volta ao ponto de partida, nestes tempos em que necessitamos ser mais ágeis, é uma boa ideia considerar essas estratégias para ter um pouco mais de controle sobre o nossos aplicativos e  criar um ambiente de desenvolvimento mais saudável e menos estressante .


Depois de tudo isso, só resta uma dúvida:


Você levou em conta os scripts de dados para fornecer uma solução integral para as suas aplicações?


Saudações!!


---


----------------------------------------------------- Autor da foto acima: brunociampi https://www.flickr.com/photos/brunociampi/2745217216
------------------------------------------------------

No hay comentarios:

Publicar un comentario