Answers: <p><a href="https://www.jetbrains.com/teamcity/" rel="nofollow noreferrer">TeamCity</a> has a <a href="https://confluence.jetbrains.com/plugins/servlet/mobile#content/view/74847245" rel="nofollow noreferrer">Shared Resources</a> build feature which allows you to define a resource which multiple Build Definitions depend upon it.  Build Definitions can either require a Read Lock or a Write Lock, you can also define if these locks are exclusive or allow a degree of parallelism.</p>
  
  <p>If we make the following assumptions about a shared environment named <em>PreProd</em>:</p>
  
  <ul>
  <li>A Shared Resource exists named "PreProd".</li>
  <li>All build definitions, such as deployments, that make any change to that environment take an exclusive <strong>Write Lock</strong> on "PreProd".</li>
  <li>All build definitions, such as non-restrictive tests, that perform read-only operations on the environment take a non-exclusive <strong>Read Lock</strong> on "PreProd".</li>
  <li>TeamCity is the only process that can do anything on PreProd, albeit perhaps via another tool.</li>
  </ul>
  
  <p>Therefore the following are true:</p>
  
  <ul>
  <li>When a deployment is happening then nothing else can use PreProd, they will be queued.</li>
  <li>When a test is running, any deployment would be queued until the tests complete.</li>
  </ul>
  
  <p>You can use a similar mechanism with <a href="https://jenkins.io/" rel="nofollow noreferrer">Jenkins</a> using the <a href="https://wiki.jenkins-ci.org/display/JENKINS/Exclusion-Plugin" rel="nofollow noreferrer">Exclusion plugin</a>.  In fact, you could build this functionality into any process using locking or semaphore - for example <a href="https://zookeeper.apache.org" rel="nofollow noreferrer">Apache ZooKeeper</a> or <a href="https://www.consul.io" rel="nofollow noreferrer">HashiCorp Consul</a>.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-17T22:01:42.150Z
Answers: Good description of ´standard' implementations of what I did put in the ´guard' idea :)
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-18T07:51:00.480Z
Answers: merci, any links to share/add to TeamCity itself, to learn more about it?
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-18T09:23:49.310Z
Answers: Absolument, I have added hyperlinks to both TeamCity and Jenkins in the answer, I can personally recommend the TeamCity course on [Udemy](https://www.udemy.com/courses/).
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-03-18T09:40:25.453Z
Answers: merci for the extra update! PS: why not also include the course link in your answer also, eg via a PS at the end? That way, if some day a moderator comes along and starts deleting comments, it's not of risk of getting lost (it happens to me quite a lot at some other SE site).
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-18T10:30:39.517Z
Answers: I'm cautious about posting links to commercial content in answers on SE sites in general.  I want to be helpful in that I recommend this course, however, as it is the only course I have taken it's very much my own opinion.
Answers: Richard Slater
Answers: CC BY-SA 3.0
Answers: 2017-03-17T20:37:30.747Z
Answers: 2017-03-18T09:18:25.603Z
Answers: 2017-03-18T09:18:25.603Z
Answers: Richard Slater
Answers: <p>This sounds like an anti pattern to me. I believe everybody or nobody should have access to all the environments.</p>
  
  <p>If users are subverting the process then I would take a serious look at the process to try and ensure it's not getting in people's way.</p>
  
  <p>Implementing an automated mechanism that enforces a specific state is also useful for encouraging people to do things the right way. This can be via Config Management or destroying any immutable instance if someone SSHs to it</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-13T20:33:58.467Z
Answers: Please check the 2nd "note" I added. Does it help to have you reconsider your first paragraph? Apart from that, I don't understand how the remaining part of your answer actually answers the "how to" part of my question. Maybe there is something I don't understand in it, so can you help me better understand your answer please? PS: Don't worry, I rarely downvote answers (if I do, I do leave comments ....).
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-14T06:14:01.987Z
Answers: Your have an xy problem https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem. I'm not answering how to implement your solution I'm answering how I would solve your problem
Answers: Robo
Answers: CC BY-SA 3.0
Answers: 2017-03-14T09:33:10.490Z
Answers: @Robo I disagree, the question on the how makes sense, without any subversion or whatever. This could just be suspending any automated update during the time of the test. You're seeing it as manual action, the point is: avoid someone else upgrading an Application A to version Y while another team is still testing application B in version X which rely on application A. This mean having a guard to avoid a test team to require an update on a dependency under test.
Answers: Tensibai
Answers: CC BY-SA 3.0
Answers: 2017-03-14T09:39:04.473Z
Answers: That was not clear from your question. In that case you need some kind of lock.
Answers: Robo
Answers: CC BY-SA 3.0
Answers: 2017-03-15T12:46:30.470Z
Answers: Please note that I just integrated (most of) @Tensibai 's comment as an extra clarification (last bullet). Hope "it" helps it make ***my*** question more clear. Maybe you (Robo) want to also review your answer as per that extra clarification? PS: merci Tensibai ...
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-13T19:58:19.967Z
Answers: 2017-03-13T19:58:19.967Z
Answers: Robo
Answers: <p>My answer in the context of the question is a very expensive test environment (like mainframes or very large telecom equipment, for example) which are expected to be shared by multiple users for multiple tests, even simultaneously.</p>
  
  <p>In many cases such equipment has a software management system responsible for, among other things, controlling software (un)installation/upgrades/downgrades/etc. Which should have some mechanism for blocking such operations (which would be, if I understood the question correctly, equivalent to freezing the environment) based on some more or less programmable policies.</p>
  
  <p>In such case a specific policy could be developed exactly to support the desired freezing schedule necessary for the test environment. Ideally automated, accepting freezing/thawing triggers from the external sources which could be the test execution wrappers or CI systems. And maybe with human-triggered overrides, if deemed necessary.</p>
  
  <p>Of course, such feature of the software management system would be helpful when testing other components of the equipment, but maybe not for tests of the software management system itself.</p>
  
Answers: CC BY-SA 3.0
Answers: 2017-03-18T08:10:03.540Z
Answers: This answer is exatly about what I'm used to (mainframes), where we do these kind of things for at least 1,5 decade or so already (before "DevOps" was born). I wonder if it would make sense to add my own answer here (to further expand on this answer, how we do this with CMN/ZMF for eg "banks"), or just take it to a new (self answered) question. What do you think?
Answers: Pierre.Vriens
Answers: CC BY-SA 3.0
Answers: 2017-03-18T13:25:13.183Z
Answers: Probably a separate one would be better - mine is mostly an opinion as I didn't experience such environment directly, I only discussed about it now and then with friends who did.
Answers: Dan Cornilescu
Answers: CC BY-SA 3.0
Answers: 2017-03-18T01:22:49.230Z
Answers: 2017-03-18T08:02:30.017Z
Answers: 2017-03-18T08:02:30.017Z
Answers: Dan Cornilescu
Body: <p>Here is a partial quote from <a href="https://devops.stackexchange.com/a/499/40">an answer</a> to the question about "<a href="https://devops.stackexchange.com/q/498/40">How to avoid continuous integration-caused instabilities in test environments?</a>":</p>
  
  <blockquote>
    <p>This environment usually freezes during the tests.</p>
  </blockquote>
  
  <p>My question: what are sample implementations of a frozen environment? I.e. what can you do to technically enforce that nobody (except if allowed by an authorized user like a release manager) will be able to change anything in such frozen environment.</p>
  
  <p><strong>Clarifications</strong>:</p>
  
  <ul>
  <li><p>I'm not talking about what (I think) is called "frozen periods" during (eg) year-end processing in banks. That is about not being allowed to apply any (repeat any) changes to production environments, to reduce the risk of new changes/fixes being introduced that may impact the year-end processing.</p></li>
  <li><p>Assume that users who are allowed to approve/apply changes anyway (such as the release manager in my example), will only do so in exceptional cases. Such as where during testing a high severity issue is encountered, for which deferring a fix to a next release is not an option (since it would production at risk if the release would be activated without such fix).</p></li>
  <li><p>This could just be about suspending any automated update during the time of the test. The point is: avoid someone else upgrading an Application A to version Y while another team is still testing application B in version X which rely on application A. This could mean having a guard to avoid a test team to require an update on a dependency under test.</p></li>
  </ul>
  
Tags: <automation><testing><configuration>
Title: How to implement a frozen test environment?
UserDisplayName: Pierre.Vriens
ThreadText: # How to implement a frozen test environment?
  
  (Asked by: username_0 on 2017-03-13)
  
  Here is a partial quote from [an answer](https://devops.stackexchange.com/a/499/40) to the question about "[How to avoid continuous integration-caused instabilities in test environments?](https://devops.stackexchange.com/q/498/40)":
  
  > This environment usually freezes during the tests.
  
  My question: what are sample implementations of a frozen environment? I.e. what can you do to technically enforce that nobody (except if allowed by an authorized user like a release manager) will be able to change anything in such frozen environment.
  
  **Clarifications**:
  
  * I'm not talking about what (I think) is called "frozen periods" during (eg) year-end processing in banks. That is about not being allowed to apply any (repeat any) changes to production environments, to reduce the risk of new changes/fixes being introduced that may impact the year-end processing.
  * Assume that users who are allowed to approve/apply changes anyway (such as the release manager in my example), will only do so in exceptional cases. Such as where during testing a high severity issue is encountered, for which deferring a fix to a next release is not an option (since it would production at risk if the release would be activated without such fix).
  * This could just be about suspending any automated update during the time of the test. The point is: avoid someone else upgrading an Application A to version Y while another team is still testing application B in version X which rely on application A. This could mean having a guard to avoid a test team to require an update on a dependency under test.
  
  **Tags:** automation, testing, configuration
  
  
  ---
  
  ## 3 answers
  
  ### Answer by username_4 on 2017-03-18. Score: 3 | Accepted answer
  
  My answer in the context of the question is a very expensive test environment (like mainframes or very large telecom equipment, for example) which are expected to be shared by multiple users for multiple tests, even simultaneously.
  
  In many cases such equipment has a software management system responsible for, among other things, controlling software (un)installation/upgrades/downgrades/etc. Which should have some mechanism for blocking such operations (which would be, if I understood the question correctly, equivalent to freezing the environment) based on some more or less programmable policies.
  
  In such case a specific policy could be developed exactly to support the desired freezing schedule necessary for the test environment. Ideally automated, accepting freezing/thawing triggers from the external sources which could be the test execution wrappers or CI systems. And maybe with human-triggered overrides, if deemed necessary.
  
  Of course, such feature of the software management system would be helpful when testing other components of the equipment, but maybe not for tests of the software management system itself.
  
  > **Comments:**
  > **username_0**: This answer is exatly about what I'm used to (mainframes), where we do these kind of things for at least 1,5 decade or so already (before "DevOps" was born). I wonder if it would make sense to add my own answer here (to further expand on this answer, how we do this with CMN/ZMF for eg "banks"), or just take it to a new (self answered) question. What do you think?  
  > **username_4**: Probably a separate one would be better - mine is mostly an opinion as I didn't experience such environment directly, I only discussed about it now and then with friends who did.  
  
  ---
  
  ### Answer by username_1 on 2017-03-17. Score: 4
  
  [TeamCity](https://www.jetbrains.com/teamcity/) has a [Shared Resources](https://confluence.jetbrains.com/plugins/servlet/mobile#content/view/74847245) build feature which allows you to define a resource which multiple Build Definitions depend upon it. Build Definitions can either require a Read Lock or a Write Lock, you can also define if these locks are exclusive or allow a degree of parallelism.
  
  If we make the following assumptions about a shared environment named *PreProd*:
  
  * A Shared Resource exists named "PreProd".
  * All build definitions, such as deployments, that make any change to that environment take an exclusive **Write Lock** on "PreProd".
  * All build definitions, such as non-restrictive tests, that perform read-only operations on the environment take a non-exclusive **Read Lock** on "PreProd".
  * TeamCity is the only process that can do anything on PreProd, albeit perhaps via another tool.
  
  Therefore the following are true:
  
  * When a deployment is happening then nothing else can use PreProd, they will be queued.
  * When a test is running, any deployment would be queued until the tests complete.
  
  You can use a similar mechanism with [Jenkins](https://jenkins.io/) using the [Exclusion plugin](https://wiki.jenkins-ci.org/display/JENKINS/Exclusion-Plugin). In fact, you could build this functionality into any process using locking or semaphore - for example [Apache ZooKeeper](https://zookeeper.apache.org) or [HashiCorp Consul](https://www.consul.io).
  
  > **Comments:**
  > **username_2**: Good description of ´standard' implementations of what I did put in the ´guard' idea :)  
  > **username_0**: merci, any links to share/add to TeamCity itself, to learn more about it?  
  > **username_1**: Absolument, I have added hyperlinks to both TeamCity and Jenkins in the answer, I can personally recommend the TeamCity course on [Udemy](https://www.udemy.com/courses/).  
  > **username_0**: merci for the extra update! PS: why not also include the course link in your answer also, eg via a PS at the end? That way, if some day a moderator comes along and starts deleting comments, it's not of risk of getting lost (it happens to me quite a lot at some other SE site).  
  > **username_1**: I'm cautious about posting links to commercial content in answers on SE sites in general.  I want to be helpful in that I recommend this course, however, as it is the only course I have taken it's very much my own opinion.  
  
  ---
  
  ### Answer by username_3 on 2017-03-13. Score: 0
  
  This sounds like an anti pattern to me. I believe everybody or nobody should have access to all the environments.
  
  If users are subverting the process then I would take a serious look at the process to try and ensure it's not getting in people's way.
  
  Implementing an automated mechanism that enforces a specific state is also useful for encouraging people to do things the right way. This can be via Config Management or destroying any immutable instance if someone SSHs to it
  
  > **Comments:**
  > **username_0**: Please check the 2nd "note" I added. Does it help to have you reconsider your first paragraph? Apart from that, I don't understand how the remaining part of your answer actually answers the "how to" part of my question. Maybe there is something I don't understand in it, so can you help me better understand your answer please? PS: Don't worry, I rarely downvote answers (if I do, I do leave comments ....).  
  > **username_3**: Your have an xy problem https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem. I'm not answering how to implement your solution I'm answering how I would solve your problem  
  > **username_2**: @username_3 I disagree, the question on the how makes sense, without any subversion or whatever. This could just be suspending any automated update during the time of the test. You're seeing it as manual action, the point is: avoid someone else upgrading an Application A to version Y while another team is still testing application B in version X which rely on application A. This mean having a guard to avoid a test team to require an update on a dependency under test.  
  > **username_3**: That was not clear from your question. In that case you need some kind of lock.  
  > **username_0**: Please note that I just integrated (most of) @username_2 's comment as an extra clarification (last bullet). Hope "it" helps it make ***my*** question more clear. Maybe you (username_3) want to also review your answer as per that extra clarification? PS: merci username_2 ...  
  
  ---
  
  