title: Best-practice for continuous integration and deployment
body: <p>Continuous integration concept has just been integrated in my team.</p>
  
  <p>Assume we have an integration branch named <strong>Dev</strong>. </p>
  
  <p>From it derived 3 branches, one for each specific current project :</p>
  
  <ul>
  <li>Project <strong>A</strong> </li>
  <li>Project <strong>B</strong></li>
  <li>Project <strong>C</strong></li>
  </ul>
  
  <p>First, Teamcity is configured on a dedicated server and it goals is :</p>
  
  <p><em>Compiles and launches unit and integration tests from versioned sources from each branch including Dev</em></p>
  
  <p>Then, of course, each project branch (A,B and C) must be tested in a cloned production environment so that UAT can be carried out.</p>
  
  <p>But I wonder what frequency should we deploy on? Everytime a source code changes ?</p>
  
  <p>Should we deploy only Dev that contains mix of the 3 projects after merging each one to it (corresponding to the reality in next production release) or the 3 projects independently?</p>
  
  <p>If Dev is deployed, potentially future changes on Dev must not be taken in account. Indeed,
  there might be a new project starting called <strong>Project D</strong> and that mustn't be part of the next release. So taking Dev for integration (UAT) is risked because deployer could unvoluntary integrate content of Project D and so environment will not reveal the reality of the next release.</p>
  
  <p>Other solution: we're not taking Dev but independently the 3 projects, so must there be 3 cloned production environments in parallel? </p>
  
  <p>If yes, UAT couldn't be reliable since behaviour of integration environment might change very often...</p>
  
  <p>Concept of continuous deployment for UAT isn't clear for me... </p>