Hello all - I'm looking to start developing a new feature within an existing application. There will be 2 other developers working on this environment simultaneously. This new feature is a large scale change will take a number of days to complete. Meanwhile, small changes within the same space are expected to be made. Deployments from our Developer.

The code for this new feature should only be deployed to our development environment but should not be be deployed to our Q/A environments.

I do not understand how we can selectively merge code between dev and Q/A servers. I need my changes to be pushed to dev, yet withheld from the other environments. Is there a way to accomplish this?

Hi David,

How are you doing your environment deploys right now? LifeTime doesn't allow you to select specific parts of the code to deploy, it works on an Espace/Application basis.

You'd need to do it manually, so you'd download an Espace from the development environment, connect to the Quality environment, do your merges there (unselecting all the components of your new feature and selecting everything that is allowed to go to QA), and then publish.

This is going to increase the complexity of your deploys by a long margin, and is very error prone. Are you certain that the new feature cannot leave development under any circumstances? Have you considered the possibility of building it side-by-side with existing code, or developing a way to disable it while it's being developed?

Afonso Carvalho wrote:

Hi David,

How are you doing your environment deploys right now? LifeTime doesn't allow you to select specific parts of the code to deploy, it works on an Espace/Application basis.

You'd need to do it manually, so you'd download an Espace from the development environment, connect to the Quality environment, do your merges there (unselecting all the components of your new feature and selecting everything that is allowed to go to QA), and then publish.

This is going to increase the complexity of your deploys by a long margin, and is very error prone. Are you certain that the new feature cannot leave development under any circumstances? Have you considered the possibility of building it side-by-side with existing code, or developing a way to disable it while it's being developed?

Hi Afonso, thank you for your reply.

At the moment, we are sharing a single environment for dev. Developers are assigned areas of the web-app and take on tasks that fall in that area. This is to minimise overwriting each other. Whenever we push to QA, we coordinate that our tasks are done and cleaned up to push onward. I suppose this is a consequence of not having our personal environments to develop on.


If the surrounding changes are small enough, you could also consider deploying them on a hotfix basis: having people working in DEV to create their changes, and then creating them in QA afterwards, leaving your larger feature isolated in DEV - you wouldn't have to deal with complicated manual merges, developers would be responsible for propagating their changes. This comes with its own dangers, obviously.

It happens in a lot of projects and it's always a tough problem. The solution is always going to depend on the nature of the larger feature, as well as the time that it will take to develop, how complex it is, whether you can enable/disable it and if the smaller tasks surrounding it are simple bugfixes or more complex issues. Hopefully reading this is at least giving you some ideas on how to proceed.

Solution

David,

This can be an issue any time you need to be working on multiple things at once.  The best solution we've come up with is to use "feature flags" or "feature toggles".  It requires some discipline on the part of the developers.  They have to learn to do things in small steps so code is never broken, and they have to learn how to unit test their feature flags.  Martin Fowler has an excellent write up on using feature flags.  We're implementing them using site properties that can be set, but there a different ways it can be done.  Hope this link helps:

https://martinfowler.com/articles/feature-toggles.html


Solution

Kevin Swanson wrote:

David,

This can be an issue any time you need to be working on multiple things at once.  The best solution we've come up with is to use "feature flags" or "feature toggles".  It requires some discipline on the part of the developers.  They have to learn to do things in small steps so code is never broken, and they have to learn how to unit test their feature flags.  Martin Fowler has an excellent write up on using feature flags.  We're implementing them using site properties that can be set, but there a different ways it can be done.  Hope this link helps:

https://martinfowler.com/articles/feature-toggles.html


Thank you Kevin. After much deliberation, this is the approach we'll be going with. We'll quarantine the controls that will activate the code in an area that will only be available in the dev server. We'll use some Site Properties to manage that aspect. We'll then move those controls to the actual UI further down the line.