Develop a service mesh solution that enables developers deploy and test multiple code versions

Question

I have a situation where we deployed apps in PaaS and the environments are limited for non-prod. The environments we have are NP, Staging, SIT, and PROD.

Devs will continue to develop and test at local boxes and when a release is announced, the environments like NP, Staging and SIT are locked for it completely, The release will go on for a week. until the deployment to PROD is completed and environments are made avalible for the next release, devs cannot do any deployment to NP, Staging or SIT environments. Post the environment's are avalible, they could deploy only to find some issues when tested with other apps in real np, staging or SIT environments and have to rework a bit again. I don't see a point of devs waiting until the other release is complete and finding out issues later deployments to the environments like NP,Srtagign and SIT and spending time reworking instead of using the time during a ongoing release to test in real environments that could help to fix the issues faster.

Current design as :

We are containerizing apps now and looking for an option to deploy multiversions in K8s.

I'm designing to have an option to dev team to deploy multiversions and test anything any time with out having to wait for environments. This will help identify the issues faster.

New design as below ...

I would need help on

1. How to keep the same URL for all versions of apps in K8s, such as app1.example.com and app2.example.com, but also passing a header (or a cookie) to identify the proper version.
2. Assuming service mesh (ISTIO) is necessary to accomplish multiversion routing based on headers or cookies, how to I maintain the configuration.
3. What are the things that I need to cover, and what is not needed? Considering Dev wont maintain more that 4 versions at any given time.
4. Any design flaws I'm over looking or any enhancments that will solve problem easily?

Thanks,

Answer 1

My experience suggests that teams never have enough environments to test the application on. So what one would really want is a number of independent environments within each tier. Ideally, they also should be easily scaled, destroyed and recreated automatically or on demand. That is achievable by using K8s namespaces, and tools like Helm allowing to deploy the whole K8s environment in one command.

I would need help on

I'll try to give a general answer to all the four questions.

I would argue that a multiversiion routing is not really needed and the solution based on it would be way more complicated than it needs to be. Moreover, if it's a client-facing app, the first ever, simplest use case is to access the application manually like a user does. And it will be impossible if one has to set the version in a header or cookie.

If you run the tests as containers within a namespace (which is basically a recommended approach with Helm chart tests, for example), you will have the same URLs automatically cause you run them within a namespace.

If you don't - it's a common thing to have multiple configurations at any tool or framework level. You can also control them centrally using configuration management and automation tools like Ansible and others.

Considering Dev wont maintain more that 4 versions at any given time

I would not rely on any specific number here. Teams grow over time, as well as their requirements and the complexity of the application they develop.