Block Deployment Still Able to be Promoted with "Any Environment" Lifecycle

Legacy Uncategorised
1

Good Afternoon,

We are currently experiencing a problem with the Block Deployment feature. For reference, we are on the pre-release 2.6.0.751 version at this time.

Due to the way we are currently running our deployments, we have two different Dev sites: one for production line of code, and one for development line of code. We run nightly deployments of the development line, and manually run deployments of the production line, both of which occur from a build server. We decided the easiest way to handle this was to create Dev and DevProd environments, in addition to our testing servers (UAT, Test, Live).

In doing this, there is no way to utilize the new Lifecycles feature to ensure that DevProd must go DevProd -> Test -> Live, and Dev must go Dev -> UAT -> Test -> Live. Therefore, i had to leave our lifecycle as a chaotic “Any Environment” lifecycle.

It appears this is causing a problem with the Block Deployment feature. We had a deployment go to one of our DevProd sites today that had an error in it, so I blocked the deployment. Unfortunately, the Promote button is still active, both from the release page, and from the deployment that occurred to DevProd. I also do not see any environments indicated in red under the listing on the release page.

Is this intended based on the structure of the lifecycle? My thought would be that I should not be able to promote to any environment at all. Additionally, can you think of a better structure for having 2 separate lines of code for the same applications, that will allow us to take full advantage of the Lifecycle feature? My only other option, that I could think of, was to create a separate “production” application for each of our applications, but that was going to be more hassle than it’s worth.

Let me know if I can provide any more information to help.

Thanks,

Sean

2

Hi Sean

Thanks for getting in touch.

The idea behind blocking deployments is that a release can’t be deployed to a later phase in your workflow, which means that you can’t deploy to a higher environment. It is quite feasible that while you might mark a release as “we don’t want this to go to production” you may want to move it to an additional test environment in the same phase.

For your workflow though, I think an additional project is the best option. We have some ideas around a release branching strategy which would solve your issues but it’s not there today. By publishing your builds into either a “prod” workflow project or a “dev workflow” project depending on your stream you can set up the lifecycle you need for each.

Sorry to be the bearer of bad news, like I said it’s something we’d like to cater for but it’s not something out of the box today.

Regards

Damian

3

Damian,

Thanks for your response. I understand that features like these need to cater to many types of possibilities for deployment to satisfy the community as a whole. Also understandable that you may want to push to another environment for the same phase.

I think for now we are actually going to drop off our DevProd environment, and just stick to a 4 environment lifecycle. Our production lines will go to the test site directly before being pushed to production, and that should work fine for us. In the future, it would be nice to have some sort of branching strategy like you mentioned, and I did take a gander at the Branching blog post, that may suit our needs.

Thanks for your time,

Sean