What's in a word. In deployments the nature of the words you use can kill you. SOA (Service Oriented Architecture) is living proof of this opportunity for confusion.
Remembering the fundamental guiding principles of SOA (see endnote below from wikipedia) we have an issue/opporunity around the concepts of interoperability, componentization, encapsulation and reuse.
To me this means that the service is independent in nature to the other services around it other than rules of interaction and to a lesser extend the platform. So when you start talking about SOA deployment there is often confusion when reviewed or implemented by the school of thought of our old systems.
Since the systems are supposed to be independent entities that do not exist if not published in the registry, if I deploy a new service and don't tell anyone, do I need to test the whole system? No! If I add it to the registry do I need to test the whole system? No!
In the old world of tight coupling there were issues when you made even the simplest of changes which called for massive regression tests.
So when we think about deployment in a SOA world we need to break it up into different types:
- Upgrade/Add Hardware
- Upgrade underlying enterprise platform that service lives on (BEA, SAP or Websphere)
- Services Deployment - New
- Services Deployment - Old - modifying an existing service, add elements or change business rules
- New customers/consumers of our services
These to me are the main points of consideration that should drive behaviour, but choose your words wisely or you will spend so much time testing that you will spend more than your development budget and that defeats the purpose.