Answers: <p>I'd investigate what would it take to bundle all these customizations into something like a per-customer configurable <em>theme</em> that can be served by a single, more generic application code.</p>
  
  <p>It probably won't be easy and it may take a long time to reach such capability, but it can be done gradually: start with the N*5 repos and, as you inch forward toward this ideal solution you'll see the deltas in the application code from the repos starting to shrink - the differences will gradually migrate towards these custom themes/artifacts. </p>
  
  <p>When there are no more app code differences left then you can replace the N*5 repos with just 5 app code repos for now common app code and N*5 theme configurations/artifacts repos. Much easier to maintain.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-05-04T16:22:12.677Z
Answers: I second this.  I had to maintain a SAAS codebase (without the fun of docker or CI) that was split over 5-6 customer branches.  We made most things configurable, and created configs for each customer...made our lives so much easier and pesky bugs squashed in one branch didn't pop up in others, because there were no others.
Answers: Marshall Tigerus
Answers: CC BY-SA 3.0
Answers: 2018-04-29T18:01:20.203Z
Answers: 2018-04-29T18:01:20.203Z
Answers: Dan Cornilescu
Body: <p>So we have 5 repositories (Individual web services ex. CMS/E-commerce and internal APIs) which are currently deployed as Docker containers.</p>
  
  <p>What we plan to do is to use these services and make a standalone SaaS for customers. This is straightforward however, each customer over here will have some kind of Business customizations (Business Logic etc) so this means based on our current deployment technique each customer will need their own 5 repositories.</p>
  
  <p>Just to explain things more clearly:</p>
  
  <p>Each customer will have their own aws instance which will be having the docker containers of our products.</p>
  
  <p>However, with this approach, we will have to create N * 5 repositories and custom deployment scripts (Ansible+Terraform) for each client. </p>
  
  <p>One solution that I had was to create individual branches for each project within the same 5 repositories however, this is not a good scalable method. </p>
  
  <p>Open to any idea, to be honest since this is something new for me. </p>
  
Tags: <docker><amazon-web-services><ansible><git><terraform>
Title: Deploying a SaaS solution which is custom for every customer
UserDisplayName: Gaurav Jagtap
ThreadText: # Deploying a SaaS solution which is custom for every customer
  
  (Asked by: username_0 on 2018-04-29)
  
  So we have 5 repositories (Individual web services ex. CMS/E-commerce and internal APIs) which are currently deployed as Docker containers.
  
  What we plan to do is to use these services and make a standalone SaaS for customers. This is straightforward however, each customer over here will have some kind of Business customizations (Business Logic etc) so this means based on our current deployment technique each customer will need their own 5 repositories.
  
  Just to explain things more clearly:
  
  Each customer will have their own aws instance which will be having the docker containers of our products.
  
  However, with this approach, we will have to create N \* 5 repositories and custom deployment scripts (Ansible+Terraform) for each client.
  
  One solution that I had was to create individual branches for each project within the same 5 repositories however, this is not a good scalable method.
  
  Open to any idea, to be honest since this is something new for me.
  
  **Tags:** docker, amazon-web-services, ansible, git, terraform
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2018-04-29. Score: 2 | Accepted answer
  
  I'd investigate what would it take to bundle all these customizations into something like a per-customer configurable *theme* that can be served by a single, more generic application code.
  
  It probably won't be easy and it may take a long time to reach such capability, but it can be done gradually: start with the N\*5 repos and, as you inch forward toward this ideal solution you'll see the deltas in the application code from the repos starting to shrink - the differences will gradually migrate towards these custom themes/artifacts.
  
  When there are no more app code differences left then you can replace the N\*5 repos with just 5 app code repos for now common app code and N\*5 theme configurations/artifacts repos. Much easier to maintain.
  
  > **Comments:**
  > **username_2**: I second this.  I had to maintain a SAAS codebase (without the fun of docker or CI) that was split over 5-6 customer branches.  We made most things configurable, and created configs for each customer...made our lives so much easier and pesky bugs squashed in one branch didn't pop up in others, because there were no others.  
  
  ---
  
  