Answers: <p>The <a href="https://docs.gitlab.com/ee/ci/environments.html" rel="nofollow noreferrer">documentation</a> shows that you can have 40+ branches with different configurations. You express concern that the configuration becomes large. With a good editor that isn't really a problem. Yet that feels wrong, right?</p>
  
  <p>With git, in general, a repository per independent deployable works better than a single repository holding many independent deployables. So an alternative layout is not 1 repo with 40 branches, but 1+40 repos. That would be 1 repo that builds the latest code and <a href="https://docs.gitlab.com/ee/workflow/releases.html" rel="nofollow noreferrer">creates releases</a>. Then 40 repos that represent the configuration to deploy a particular release of the code configured for one website. The 40 repos that deploy the code can hold the 40 per-website configurations and a standardised build script that simply downloads the right release of the code to deploy along with the website configuration into the environment. </p>
  
  <p>We use 1+N+M git repos. We have 1 repo that holds the deploy scripts. They are versioned and released. We have N repos that build the different apps into releases. Currently, two php apps and two react apps that work together but are deployed and upgraded independently. Then M repos that represent the environments/sites we deploy into which is currently only staging and live. </p>
  
  <p>We are using k8s (OKD) and the deployment scripts are using helm. That just means that our deployment scripts and environment setup are simpler and rollback/downgrade is fully automated. We don't actually download the app to deploy during our build. Instead, we simply push out the docker registry tag of the version of the code we want to deploy into a given environment. </p>
  
  <p>I started a project to opensource our approach to deploying apps from git which is called <a href="https://github.com/ocd-scm/ocd-meta/wiki" rel="nofollow noreferrer">OCD</a>. It is still a work in progress but it demonstrates some of the above ideas. </p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-30T18:09:51.210Z
Answers: How do you pass docker tag from build repository to deploy repository without manually adding it
Answers: azeko
Answers: CC BY-SA 4.0
Answers: 2018-11-30T18:40:25.983Z
Answers: @azeko a release event in git fires a [release git webhook](https://developer.github.com/v3/activity/events/types/#releaseevent) that triggers a build that makes an image that is given the same tag in the docker registry. then to release that version of the code you tag the repo that holds yaml that names all the versions to deploy to the environment. a second release event in git then runs a build that deploys look at the versions named in the yaml and applies that to the environment. various build tools can be configured to automatically build or deploy or both on git tags.
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2018-11-30T18:49:12.177Z
Answers: @azeko to your specific question if you run a docker build due to a git release event you can parse the git tag out of the release event payload, git checkout that version of the code, build it, push it to the docker repo, then tag it in the docker repo with the same tag. with OKD builds that OCD manages its done slightly differently to work around that OKDs s2i buids don't make it easy to just do a docker tag at the end.
Answers: simbo1905
Answers: CC BY-SA 4.0
Answers: 2018-11-29T22:46:34.510Z
Answers: 2018-12-02T15:24:07.007Z
Answers: 2018-12-02T15:24:07.007Z
Answers: simbo1905
Body: <p>How to deploy multiple instances (40+) of the same application with gitlab? (it is a simple tomcat web app)</p>
  
  <p>I want to be able to individually upgrade/downgrade them using web interface.</p>
  
  <p>We already have a working gitlab+docker pipeline that deploys one instance of an app. We are not using k8s yet.</p>
  
  <p>Should we create gitlab environment for each instance? Do we have better options besides gitlab environments?</p>
  
  <p><em>Update</em>:
  Instances (websites) do differ, they have the same codebase but different configuration. Right now the scaling is not a priority, what we really want is to have an interface to add, deploy, upgrade and downgrade websites. I've tried gitlab environmets on a smaller project and it's really awesome when you have like one or two websites, but when you have 10 or more and you have one environment for each website .gitlab-ci.yml grows exponentially.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-11-28T03:57:24.977Z
Comments: If you want to "be able to individually upgrade/downgrade them using web interface." you probably want to have individual jobs for them. However, this doesn't seem like good practice. Perhaps you should consider Docker Swarm (if you're not ding k8s) and apply [rolling updates](https://docs.docker.com/engine/swarm/swarm-tutorial/rolling-update/) to the running services?
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2018-11-29T09:49:41.197Z
Comments: *same codebase but different configuration* I wonder does the configuration change only in one file? You can have multiple environments and use yaml inheritance https://stackoverflow.com/questions/44287955/same-steps-for-multiple-named-environments-with-gitlab-ci
Comments: Kyslik
Tags: <containers><gitlab><continuous-deployment><infrastructure-as-code>
Title: How to handle large deployments using tools like gitlab and docker
UserDisplayName: azeko
ThreadText: # How to handle large deployments using tools like gitlab and docker
  
  (Asked by: username_0 on 2018-11-27)
  
  How to deploy multiple instances (40+) of the same application with gitlab? (it is a simple tomcat web app)
  
  I want to be able to individually upgrade/downgrade them using web interface.
  
  We already have a working gitlab+docker pipeline that deploys one instance of an app. We are not using k8s yet.
  
  Should we create gitlab environment for each instance? Do we have better options besides gitlab environments?
  
  *Update*:
  Instances (websites) do differ, they have the same codebase but different configuration. Right now the scaling is not a priority, what we really want is to have an interface to add, deploy, upgrade and downgrade websites. I've tried gitlab environmets on a smaller project and it's really awesome when you have like one or two websites, but when you have 10 or more and you have one environment for each website .gitlab-ci.yml grows exponentially.
  
  **Tags:** containers, gitlab, continuous-deployment, infrastructure-as-code
  
  > **Comments:**
  > **username_1**: If you want to "be able to individually upgrade/downgrade them using web interface." you probably want to have individual jobs for them. However, this doesn't seem like good practice. Perhaps you should consider Docker Swarm (if you're not ding k8s) and apply [rolling updates](https://docs.docker.com/engine/swarm/swarm-tutorial/rolling-update/) to the running services?  
  > **username_2**: *same codebase but different configuration* I wonder does the configuration change only in one file? You can have multiple environments and use yaml inheritance https://stackoverflow.com/questions/44287955/same-steps-for-multiple-named-environments-with-gitlab-ci  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_3 on 2018-11-29. Score: 3
  
  The [documentation](https://docs.gitlab.com/ee/ci/environments.html) shows that you can have 40+ branches with different configurations. You express concern that the configuration becomes large. With a good editor that isn't really a problem. Yet that feels wrong, right?
  
  With git, in general, a repository per independent deployable works better than a single repository holding many independent deployables. So an alternative layout is not 1 repo with 40 branches, but 1+40 repos. That would be 1 repo that builds the latest code and [creates releases](https://docs.gitlab.com/ee/workflow/releases.html). Then 40 repos that represent the configuration to deploy a particular release of the code configured for one website. The 40 repos that deploy the code can hold the 40 per-website configurations and a standardised build script that simply downloads the right release of the code to deploy along with the website configuration into the environment.
  
  We use 1+N+M git repos. We have 1 repo that holds the deploy scripts. They are versioned and released. We have N repos that build the different apps into releases. Currently, two php apps and two react apps that work together but are deployed and upgraded independently. Then M repos that represent the environments/sites we deploy into which is currently only staging and live.
  
  We are using k8s (OKD) and the deployment scripts are using helm. That just means that our deployment scripts and environment setup are simpler and rollback/downgrade is fully automated. We don't actually download the app to deploy during our build. Instead, we simply push out the docker registry tag of the version of the code we want to deploy into a given environment.
  
  I started a project to opensource our approach to deploying apps from git which is called [OCD](https://github.com/ocd-scm/ocd-meta/wiki). It is still a work in progress but it demonstrates some of the above ideas.
  
  > **Comments:**
  > **username_0**: How do you pass docker tag from build repository to deploy repository without manually adding it  
  > **username_3**: @username_0 a release event in git fires a [release git webhook](https://developer.github.com/v3/activity/events/types/#releaseevent) that triggers a build that makes an image that is given the same tag in the docker registry. then to release that version of the code you tag the repo that holds yaml that names all the versions to deploy to the environment. a second release event in git then runs a build that deploys look at the versions named in the yaml and applies that to the environment. various build tools can be configured to automatically build or deploy or both on git tags.  
  > **username_3**: @username_0 to your specific question if you run a docker build due to a git release event you can parse the git tag out of the release event payload, git checkout that version of the code, build it, push it to the docker repo, then tag it in the docker repo with the same tag. with OKD builds that OCD manages its done slightly differently to work around that OKDs s2i buids don't make it easy to just do a docker tag at the end.  
  
  ---
  
  