How to manage shared service deployment dependencies

[Cen giz]

Hi All,

In our enterprise, there are generic data services used by several departments. Each department asks for enhancements on these services.

There are times that the enhancements are finalised within the same week and to be released in that weeks release train.

But each department(user) wants to test it all to make sure the enhancement from other department did not break the service. 

Thus, until both department's own QA agree on the results, the service can't be released. (Thus creating inter department decencies). 

How to resolve this issue? 

They ask me to split the service so that each channel has its own service to maintain. 

But that is wrong approach as this will not be a generic micro service but project level service per user/customer. One option is to make one department to wait for the next release but that also delays the time to market.

Any ideas from DevOps experts?

BR,

Cengiz

[Josiah Carberry]

Is it possible to build into the application switches that allow you to roll out the change by setting a switch for each user or department, so that one department's hesitancy does not slow down the other departments? Also, is there an issue of trust among the departments? Can you improve communications about deployments in attempt to increase trust levels?

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.
To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Cen giz]

Hi Robert,

Thanks for the comment. Unfortunately, departments do not coordinate and all they care is their own piece. (You know in big enterprise, the team work is none to zero). You are proposing to use switches per department. Does it mean that the roll out will only release the code per department? I did not get it properly. The code is generic. Are you proposing that each enhancement per department will only be available to that department?

thanks..

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdelivery+unsub...@googlegroups.com.

[Josiah Carberry]

What I mean is to embed software switches in app that allow you to enable (or disable) a given function per session. If a department approves of the change,then all members of that department see the version with the switch on. Otherwise, the switch is off. This technique can be used for many other purposes, too. So the code remains the same for everyone, but it behaves differently according to who is using it.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.

[Cen giz]

Thanks Robert. I think, you are mentioning feature toggles. Of course they come with a price:

"As more flags get added, testing of the application becomes harder and more expensive, and can lead to an explosion of combinations: If a is on and b is off and c is on and d is off then… what is supposed to happen? Fowler says that you only need to test the combinations which should reasonably be expected to happen in production, but this demands that everyone involved clearly understand what options could and should be used together – as more flags get added, this gets harder to understand and verify. 

And other testing needs to be done to make sure that switches can be turned on and off safely at run-time, and that features are completely and safely encapsulated by the flag settings and that behaviour doesn’t leak out by accident (especially if you are branching in code and releasing work-in-progress code). You also need to test to make sure that the structural changes to introduce the feature toggle do not introduce any regressions, all adding to testing costs and risks.

More feature flags also make it harder to understand how and where to make fixes or changes, especially when you are dealing with long-lived flags and nested options."

[Denis Krizanovic]

Hi Cen,

Do some research on Consumer Driven Contracts. I think you'll find that it will help.

The trick with this is the change management around the division of labour. It could be that your team writes the critical mass of tests for the first one or two consumers, but it should show the power of it. This sentence will make more sense once you get your hands dirty with one of the implementations.

regards,

dk-

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdeliv...@googlegroups.com.

[Zeitgeb3r]

You may have a problem with Bounded Context (concept from Domain Driven Design).

Your bounded context probably spans multiple departments, when it shouldn't.

Think about your business domain entities and whether they can be localized into one department.

Common Information Model (CIM) is an old SOA term where domain entities are agreed upon by several departments

where a change in one entity affects multiple departments. The industry is no longer in favor of CIM.

You need to break down your app, and establish a Bounded Context between departments.

[Cen giz]

Hi,

Thanks. Also, there is an conceptual issue with our deployment process. Each department wants to make sure once they test and deploy, they will more secure. If some other party is involved at the same time, they are scared their work will break and they both feel to test the code before releasing.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdelivery+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdelivery+unsub...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Continuous Delivery" group.

To unsubscribe from this group and stop receiving emails from it, send an email to continuousdelivery+unsub...@googlegroups.com.

[Cen giz]

Hi,

How to make department based boundaries. Order is a domain. How to make it department specific?

[Zeitgeb3r]

In this Martin Fowler's short article (below),

the Sales Department has a `Customer`, but the Support Department also has a `Customer`.

The Sales Department has a `Product`, but the Support Department also has a `Product`.

I suggest you read the `bounded context` chapter of the book by Eric Evans : Domain Driven Design.

https://martinfowler.com/bliki/BoundedContext.html

[Thierry de Pauw]

Hi Cen,

+1 for investigating Consumer Driven Contracts.

Consumer Driven Contracts is a pattern for evolving services where each consumer (in your case a department) captures its expectations of the provider (your generic service) in a separate contract. That contract is expressed using tests that consumers write against the provider showing how the provider is being used by the consumer.

The contracts of all the consumers are then shared with the provider so he can gain insights on the obligations he must fulfill for each individual client.

The provider creates a test suite using all the tests he got from his consumers to validate these obligations. And making sure when the service evolves no contracts are being violated.

See this article by Martin Fowler on Consumer Driven Contracts for more olinformation:

https://martinfowler.com/articles/consumerDrivenContracts.html

And this ThoughtWorks Tech Radar blip on Consumer Driven Contracts where they state the practice is an essential part of a mature microservice testing portfolio, enabling independent service deployments.

https://www.thoughtworks.com/radar/techniques/consumer-driven-contract-testing

Cheers,

Thierry

--

Sent from a device without keyboard. Please excuse brevity, errors and embarrassing autocorrections.