A manutenção de schema de banco de dados é algo importante e delicado em qualquer projeto de desenvolvimento de software. Quando o assunto é banco de dados, todos os desenvolvedores do time precisam estar na mesma página para que possamos realizar mudanças rápidas e com o mínimo de propensão a falhas possível. Com o intuito de atingirmos esses objetivos é importante que o schema do banco de dados esteja protegido pelo nosso controle de versão, e que de preferência, faça parte do processo de Integração Contínua do projeto.

Normalmente o processo de atualização e manutenção de schema de banco de dados é realizado de maneira manual através da criação de scripts SQL e/ou utilização de softwares que geram estes scripts a partir da comparação de dois bancos de dados. Apesar deste processo funcionar em muitos projetos existentes, ele exige muita intervenção manual, o que pode acabar atrasando o lançamento de uma nova versão do sistema e prejudicando os processos de Integração Contínua do projeto.

Uma maneira interessante de abordar a manutenção de schema de banco de dados é através da utilização de migrations. Neste post irei explanar um pouco sobre migrations e demonstrar uma abordagem de como utilizá-las em projetos .NET através de um ótimo framework, o FluentMigrator

No momento em que escrevo este post estou trabalhando em uma aplicação desktop para Windows desenvolvida na plataforma .NET. Com a primeira versão que será entregue para os usuários finais quase pronta, nossa equipe sentiu necessidade de colocar em prática o processo de Integração Contínua. Para atingir tal objetivo precisaríamos configurar uma ferramenta que nos auxiliasse a automatizar esse processo, e para isso escolhemos um servidor de Integração Contínua chamado Jenkins.

Não tenho a intenção de me aprofundar muito nos processos relacionados a Integração Contínua neste post, a ideia é documentar algumas dicas que encontrei durante a configuração do Jenkins para o nosso cenário atual. Espero que possa ser útil para mais pessoas, boa leitura. ;)

Como programador algumas das minhas preocupações estão relacionadas a produtividade e a eficiência. Em certos momentos eu me pergunto: como posso fazer mais em menos tempo e com a melhor qualidade possível? Em busca de uma resposta para essa pergunta me deparei com uma técnica que venho tentando aplicar no meu dia a dia, e gostaria de compartilhar minhas opiniões sobre ela com vocês.

Escrever um blog é algo que penso em fazer há algum tempo, mas sempre me preocupei em não ter algo para escrever ou não ter tempo para mantê-lo, e a ideia acabou sempre ficando em segundo plano.

Mas essa ideia voltou a tomar forma ao ler o post On Having Something to Say escrito por Chad Fowler em seu blog. Nele, Chad Fowler comenta sobre seus receios ao ser convidado para falar/escrever sobre suas experiências como programador (como na primeira vez em que foi convidado para palestrar em um evento ou quando foi convidado a escrever um livro sobre Ruby On Rails). Ocasiões em que ele se perguntava, “But, why? What do I have to say? I’m still learning, after all”.