Anything we can do to automate our builds and deployment should be considered. After all, the point isn’t just to write code, but to deploy working code. So what if we did the automated builds and deployed them to development or QA? No errors, so I’m good, right?
Not so fast. Go back to what Martin Fowler says about testing in continuous integration. Builds should be self-testing. For instance, simply deploying T-SQL code to a database without errors is not the end. That’s merely the beginning. At this point you know that there aren’t any obvious syntactical errors. That doesn’t mean the T-SQL code works according to specification. It doesn’t mean that a view that you didn’t drop and create is okay. After all, if you change the underlying objects, that view might not work any more. Testing the build is important. And having all the tests needed to sufficiently check out the functionality of the code is essential.
Actually, more testing should be done that just checking bits of functionality like we typically do with unit or module tests. At some point during the process you should also be testing in production-like conditions. Can you have Continuous Integration (CI) or Continuous Delivery (CD) without proper testing? No, you can’t. You can have something that looks like CI or CD, and you may even call what you have by one of those names, but you don’t have CI or CD.
The fact of that matter is that you want testing; actually, you want as much automated testing as is feasible. Speeding up the process doesn’t mean end users are suddenly okay with getting buggy code. And we as IT professionals shouldn’t be okay with that, either. We can still ship and test. We just have to commit to test. Yes, testing will add time to every build cycle. However, it’s a necessity for every build cycle if you’re doing builds right. Simply compiling the code isn’t adequate testing. It’s merely the first test of many more.
Databases - Infrastructure - Security 