PowerShell has become the primary scripting language for the Microsoft stack, and Git the prevalent source control tool for everyone. That's still a viable route, but half a decade is an eternity in our industry and other technologies and tools have risen in popularity. When I posted my original article on this topic, in 2013, it used SVN and Jenkins, and proved very popular. This article is all about setting up the plumbing that will allow you to put CI theory into practice, for databases. The theory behind CI is that if we integrate code into a shared repository several times a day, and then verify each commit by running an automated build, and subsequent tests, then we detect and eradicate problems early, and improve the quality of our software. Over time, database changes become easier, and the database build and deployment processes get more predictable, and far less likely to introduce problems into the production systems. Bugs, introduced by coding errors or by new versions of third-party components, become much easier to find and remove because we know that the problem was caused by a change made since the last successful integration. In a Database Continuous Integration (CI) process, we establish a working version of the database quickly, integrate subsequent changes as frequently as possible, and run tests each time to prove that the database still works.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |