Closing the Loop on Continuous Build and Integration
We have been talking about how to release software reliably, what tools are needed, and how to setup your environment for continuous integration.
In the perfect world your process starts from the large idea and is incrementally reduced to the smallest detail. The end result is code meeting your requirements.
- Someone begins by defining the problem the software solves
- Those large problems are then brought to the project team and broken down into designs and tasks to solve the problem. Test cases are established to verify the created software meets those requirements.
- Either tests or code are written first…but neither is complete until both are complete. The reason for this is demonstrated by the next step.
- Completed software capable of fulfilling the test requirements is committed to the source tree. The software in version control is built and all unit tests are executed. Results of the build for compilation success and unit test pass/fail are published.
- Integration tests may be executed on a different schedule. They may not be performed with each build due to complexity or time. Regression tests and stress tests may also be performed.
- Since each build is a complete release, it is possible then to publish new code into a production environment with relative ease since you have been doing a production release on a regular basis.
That is a pretty big process. It requires a lot of communication at each step of the way. In order to assure each requirement established in step 1 is completed, and do it with each commit to version control, only an automated build and test system will allow you to meet those requirements incrementally without fail. Instead of having to wait until an entire application is completed before requirements may be validated, requirements may be validated using unit tests in portions of code that are never exposed to the end user.
All of this is pretty straight forward to setup using a comprehensive tool like Team Foundation Server or integrating separate tools. Personally, I don’t have a preference.
What is difficult to do is to track and manage database changes in a synchronized manner with the rest of your software. Lets be honest here…databases contain software also, not just data. For example, a database enforces business rules through constraints. Even though it is declarative in nature, it is still code implementing a requirement and needs to be validated as meeting requirements.
Change of these database rules is even harder to manage and keep in synch with your application code. Perhaps adding a column to a table is required for your next release to work. You need to have the addition of the column be part of your continuous integration process. In this case, either you test for the existence of the column before adding it, so you can do it over and over, or you have a baseline database you restore as a starting point of your continuous integration.
Well finish up this discussion tomorrow with more on this matter, and talk a little bit about how other vendors address this issue.
Share your insight on continuous integration in a database world by sending your comments to btaylor@sswug.org.
Cheers,
Ben
SSWUGtv
With Stephen Wynkoop
Budgets, Chargebacks, and ROI — oh my! Figuring out the value of your IT organization.
Watch the Show
$$SWYNK$$
Featured White Paper(s)
Achieve an astounding return on investment with Toad® for Oracle
read more)
Featured Script
dba3_MS_ScriptsToTransferLoginsAndPasswords_2K5
2K5 version for tf from 2K5 to other 2K5 DBMSs… (read more)