Continuous Delivery & GitOps

Your idea is appreciated and will be reviewed by our Product Management team. All posts are viewable by Harness users.
Service parallel execution and Environment parallel execution do not work together correctly
When making use of both Multi-Service and Multi-Environment deployments, it seems to me like the Parallelism does not behave as intended. With "Deploy in Parallel" OFF for both Services + Environments it deploys each service to each environment in the order the Services and Envionments are defined (which is correct) With "Deploy in Parallel" ON for both Services + Environments it deploys all services to all environments in an arbitrary order as delegates complete tasks (also correct) But if you put "Deploy in Parallel" ON for Environments, but OFF for Services what I would expect to happen is either: All deployments for the first service must complete (and can run on multiple environments at a time) before the next service's deployments start OR The deployments run on multiple environments in parallel and can continue on to run later services provided the earlier services have deployed to a given environment However this is not what happens - it runs everything in Parallel and in an arbitrary order (after the initial set of tasks) which is wrong, and makes it un-usable for any case where the services have interdependencies requiring that they don't get deployed in an order that isn't expected. And if you check the Harness docs here: https://developer.harness.io/docs/continuous-delivery/x-platform-cd-features/advanced/multiserv-multienv/ They appear to describe that this feature should operate as I expect above (for my option (1) as far as I can see) > You can deploy services to environments and infrastructures in parallel or serial, with the following options: > Services in parallel to environments in parallel. > Services in parallel to environments in serial. > Services in serial to environments in parallel. > Services in serial to environments in serial. I realise this has now been lodged as an "enhancement" request but I do really believe it is a bug, as this doc describes exactly the behaviour I think it should have (but does not)
1
·

under review

Load More