We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

A dream of continuous deployment for Web User Experience/Process

Vote 0 Votes

I have looked at "Continuous Deployment: The Dirty Details" by Mike Brittain in SideShare posted on Jan 29, 2013, and found 3 nonsense cases in this overall good presentation.

1. Presentation states, "Architecture largely does not matter" while deployments a claimed every 15-20 min. It is an obvious absurd for monolithic Web applications (as the most of them are) because any change in such an architecture requires regression testing that, depending on the internal logic of the application, may take days in spite of an automation.

That is, an architecture does not matter if the change does not matter. Otherwise, it is the very architecture of the Web application that define granular composable and independently changeable services/components for a rapid delivery and this has nothing to do with code development and delivery itself.

2. "Automated test after deployment". This is not a new type of testing and only I know about it for about 15 years already. However, for all these years nobody came with an idea to expose not-tested product (each new deployment makes running product changed; saying that Deployment ≠ Product is an absolute marketing buzz) to the consumers. In my practice, deployed but not tested products were placed into so-called quarantine where consumers could not access it. How one can really deploy a change in the live Web application and restrict access to it until testing is done in the public Web? Are we going to throw away all our experience in SW development because some new developers want (finally) to put their hands into the production environment?

3. "Your assumptions will be wrong once you've scaled 10x" This is a classic warning for those who jump into coding right away - as Mike recommends - or if architecture does not matter. Any experienced Architect, especially Service-Oriented Architect (and only services can deliver multiple independent deployments at once by the definition of services) knows that the OASIS RA for SOA standard requires to provide a default scalability of 300x. Developers do not know about this and consider such requirement a waste because designing and constructing such scaling capabilities is much more complex and time consuming task than to scrabble a code in a hap-hazard manner and deploy it (for the consumers to suffer).

I see that Web development is trying to get out of hands for the sake of making developers an unavoidable part of the products (while there is a strong flow of replacing development by integration of available services in the Web and Cloud).


Website counter


| Leave a comment

Hey, this is a really interesting blog, thanks!

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives