-2

We have a series of environments; Let's call them Development, Integration, Business and Production.

As a rule, we do not let master get deployed beyond Development, meaning any code which is to be tested by the business in the Integration or Business environments must have a pull request approved.

The problem arises when we want to test code in the Integration environment, for example, but cannot allow the code to be merged into master. Wanting to test in that environment might be for any number of reasons, including more Production-quality data, more data or more servers, etc.

This is, of course, a model which a lot of organisations follow, but I surmise that a different deployment path, which ends at Business and not Production would be a safe alternative for deployment of non-master code.

Is it wise to ensure that non-master branches never go beyond Development?

Improve this question
3
  • 1
    Testing code that is not just about to go to production in. the next release can be extremely useful. If you deploy code from a more experimental branch to Integration, can you later reliably. deploy the current code from master? Or is the Integration environment somehow tainted by the experimental deploy? Can you revert the Integration environment to a known base state after testing experimental code? Commented Jun 15, 2020 at 15:55
  • I agree that testing developmental code in non-dev environments is very useful. Yes, we can deploy various versions of the code without impacting other versions when they are deployed. eg: There is no code-first DB update applied. Commented Jun 16, 2020 at 5:44
  • 1
    Would be nice to know why this got 2 close votes. Commented Jun 16, 2020 at 5:44

1 Answer 1

Reset to default
2

There are different solutions to the described problem, but allowing to test other branches in an integration environment is only one approach. Moreover, as noted in a comment, it is only sensible if you are sure other branches won't affect the integration environment in an undesirable manner. This, however, depends heavily on how your system is structured, if a version created from a different branch can potentially corrupt test data (or other parts of the Integration environment), or not. So here are some other options, out of my head:

  • Provide the things / resources your devs require (like "production-quality data, more data or more servers", as you wrote) for the development environment as well.

  • If "Development Environment" means "local environments for each dev", you may not be able to afford that many resources. For that case, provide those resources in a specific test environment which can be shared among the dev team.

  • Depending on how your system is structured, the test environment may be able to share some server resources, database resource, web server resources with the integration environment, but without interfering with it in a way it could corrupt it.

  • Change the "code which cannot be allowed to be merged into master" into code which can be allowed. For example, if it is an experimental feature, it may be hidden behind a feature toggle which will only be activated in the Integration environment, but not in a Production environment. Of course, the code changes should be stable enough not to affect other, non-experimental features.

  • a combination of the above points.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.