title: Continuous Integration Server Setup: From Dev to Production
body: <p>We are in the process of re-configuring our server environment, from Development to Production.  All servers will be Windows 2008 servers running as VM's.  We will be using TeamCity for Continuous Integration and SubVersion as our Version Control System.</p>
  
  <p>After reading some of the recommendations, here is what I am planning on going with so far (not including any redundancy, disaster recovery, etc...):</p>
  
  <ul>
  <li><strong>Production:</strong> (1) Web Server + (1) DB Server</li>
  <li><strong>Staging:</strong> (1) Web Server + (1) DB Server</li>
  <li><strong>Build:</strong> (1) SVN + TeamCity Web&amp;DB + (1) TeamCity Agent</li>
  <li><strong>Development:</strong> (1) Web/DB Server</li>
  </ul>
  
  <p>So a total of 2 Production + 2 Staging + 2-3 Build + 1 Dev = 7-8 Servers</p>
  
  <p>My questions were:</p>
  
  <ol>
  <li><strong>Should SVN be on a dedicated Server, or can it live on the Dev server?</strong>
  
  <blockquote>
    <p><strong>Answer:</strong> Concensus so far seems to be that SVN <strong>should not</strong> be on the Dev server.  It should either be standalone, or could be paired up on the same server as TeamCity.</p>
  </blockquote></li>
  <li><p><strong>Should TeamCity be on a dedicated Server, or can it live on the SVN server?</strong></p>
  
  <blockquote>
    <p><strong>Answer:</strong> Concensus so far is that TeamCity <em>could</em> be on the same server as SVN, particularly if the TeamCity Agents and SQL DB are on separate servers.</p>
  </blockquote></li>
  <li><p><strong>Any other recommendations, best practices?</strong></p>
  
  <blockquote>
    <p><strong>Answer:</strong> TeamCity should be split up across 3 server instances: One for TeamCity Web, one for TeamCity Agents, and one for the TeamCity SQL DB.</p>
  </blockquote></li>
  </ol>
  
  <p>I'm trying to have a solid best-practice setup while minimize server sprawl.</p>