1

I had a basic question regarding using a git repository in different environments. I'm more of a Sys admin than a web developer, so the teams I've worked on before just worked right in the master, which obviously isn't the right way to do it.

I'm setting up a dev/prod/stage environment for a small company, and the Git repo has master/stage/dev branches. Locally, I just clone the git repo, then git checkout development, which works fine, but I was wondering what the best way to do that in the dev/stage/prod servers would be?

To me, it seems like checking out the entire repository in the environments, then just get checkout <environment> might not be the right way to do it, since the prod only needs the production branch, dev only needs development, etc.

1

You can do it with individual developers working in branches and then merge into master as required, then just deploy from master into each of your environments.

Or you can do it via top level branches (development, acceptance, production, etc) as you suggest. At some point, the logic of what goes into each environment needs to be handled. And the way you suggest is about as good as any.

It's worthwhile looking into something like Ansible (https://www.ansible.com/). We've recently employed this at the company where I work and it's an excellent way of pushing out varying builds to different servers based on configuration and templating. It works best from a Unix based control machine to push the changes to whatever machines you desire, so it's worth bearing that in mind, as you may need to build a Unix VM as your control machine and install Ansible on it. I'd also recommend Vagrant to manage this (https://www.vagrantup.com/).

You could also have a Jenkins server that manages each of the builds for each of the branches and then simply deploy the binaries to each server via some other process, such as Ansible or some batch program.

Hope that helps answer your question.

| improve this answer | |
  • 1
    Also worthwhile using tags in Git to baseline particular versions of the application you wish to deploy. Just an additional suggestion :) – ManoDestra Feb 24 '16 at 16:16
  • I havent ever heard of Ansible before, were using Jenkins for deployments, is Ansible something that could be used in addition to Jenkins? Or are they meant to accomplish the same task – Justin Feb 25 '16 at 16:47
  • At my company, we are using them in conjunction with each other. Ansible is a means to configure multiple servers remotely, install software, applications, etc. We have automatic builds of our applications on Jenkins. These builds are then pushed to a cloud bucket. And Ansible can then deploy to all our customers' machines with ease, ensuring that all prerequisites are met on the target machines. – ManoDestra Feb 25 '16 at 16:53
  • ++ @ManoDestra you may want to edit the tag comment into your answer. Particularly since you mentioned using a single master branch instead of master/dev. Deployments can git checkout tags/v2.3. – RubberDuck Jul 23 '16 at 21:10
0

The typical way to do this is to have a branch for each feature to merged in to master when done. For production releases, make a release branch off master. For e.g. nightly builds, just run the latest master. You shouldn't need any long-running branches except master and published release branches.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.