|
view as a single page
by Max Guernsey, III - Managing Member, Hexagon Software LLC
Introduction
This article builds upon the concepts laid out in its predecessors. If you have not read the
introduction,
Part I,
and Part II,
it is recommended that you do so now.
For those you who have, here is a quick refresher on Part I and Part II of this series:
In Part I,
we discussed evolutionary thinking in software development – a major player in emergent design – and found that it
is a great fit for software but doesn’t really work for databases. A better analogy is metamorphosis, which also
permits emergent design.
In Part II,
we discussed deployment. We saw that most of the mechanisms used were fundamentally unreliable or manual.
We hypothesized that this might be because we are trying to apply deployment models developed for software –
where builds are reliable and generally happen as a separate step from deployment. Finally, we came to the conclusion
that database deploys are database builds. Because of this fact, a “build in place” mentality might be more useful than
a “deploy to a place” mindset.
In many respects, this installment is a continuation of
Part II
that “closes the loop” with
Part I.
We will cover how testing works in software and how it works in databases. Of course, we will find the differences,
and see if there is a way we can reinvent the practice of testing software in the database domain.
Related Links:
Introduction to this Series,
Part I: Evolution,
Part II: Deployment,
DataConstructor
|