We have a single git repository on a test server (let's call it test1). The repository is very simple, just master no branches or anything fancy. The goal of this repo is to track changes to /etc/puppet and all of its sub folders. It's usually clean and synced with head.
Now we want to copy everything in test1:/etc/puppet to a production server (let's call it prod1) while maintaining a proper git workflow between to two machines. Whenever changes on test1 are ready for production, we want to use git to push them from test1 to prod1. The goal here is to be able to quickly revert back changes on prod1 if anything breaks.
This is what I have of so far:
- Setup a bare git repo (git init –bare) on test1:/opt/puppet.git to act as an intermediate server.
- Push data from test1:/etc/puppet to the bare.
- On prod1 init a new repo in /etc/puppet
- Add test1:/opt/puppet.git bare as remote to prod1:/etc/puppet
- Pull master data on from test1 to prod1 whenever we want to apply changes to production.
What are your thoughts? Should we continue to use a single master branch or we need to create a new devel branch? If we create devel branch, how do we use it with the newly created bare repo?
Best Answer
If I summarize your request, what you want, is to have an architecture with 1 git server which receives all the pushes from users, and automated pushes to prod when it's ready.
This is exactly what is done with architectire based on gerrit review system for instance. The workflow is as follow :
So the good point here is that nobody (if properly configured) can push to master without minimal review and basic test. So you master branch from prod is (almost) always clean.