title: Versioning SOA platform Across DEV,UAT environment
body: <p>We are trying to build a platform. There are approximately 30 services around(UI,WcF,Rest,Api,scheduler,etc). After a lot of development days finally we are going out of the house. But we want to control the versioning carefully. It is time to find the right way to do that.</p>
  
  <p>Now we have simple folder structure in SVN like below</p>
  
  <p>svn:</p>
  
  <ul>
  <li>branches</li>
  <ul><li>1.0.0</li>
  <ul><li>FrontEnds</li><ul><li>Service1</li><li>Service1</li></ul></ul>
  
  <ul><li>Backends</li><ul><li>Service2</li><li>Service3</li></ul></ul>
  </ul>
  </ul>
  
  <p>There are CD/CI pipelines with TeamCity and Octopus.
  Once we finished the first phase of development we are going to deploy it to the User Acceptance Test Environment(UAT) and each service uses the same version number. </p>
  
  <p>But we have got lots of ideas to do. We would like to create new branch called 1.0.1 and start development. </p>
  
  <p>Consider we create our new branch 1.0.1 and start implementing the new enhancements. Meanwhile there is a bug shown up from UAT. Of course we need to implement the fix to the novel branch.
  What are the best ways to handle this situations.</p>
  
  <p>Would it cause any problem to use same version number for each service?</p>
  
  <ol>
  <li><p>We  can take only the specific services while creating a new branch, configure Teamcity for them and Deploy the specific packages via Octopus.</p></li>
  <li><p>We can take hole platform to the new branch, make tiny changes on Teamcity(svn adress,etc), and deploy specific packages via octopus. But it will build hole platform again in the Teamcity any reason.</p></li>
  </ol>
  
  <p>There is huge mess and I confused so much.</p>