CODEWITHSUNDEEP
git
jparram
jparram

Reputation: 804

Mirror production git repo in staging environment

We have a staging environment and a production environment. We can do whatever we want in staging to test new continuous integration definitions/builds/releases etc... Each environment has a git repo.

Currently, I have two local repos. One for staging and one for production. 99% of the time we are working in production because it is not that often that we are changing build/release definitions. However, we are currently making changes and I need to update the staging git repo code with the production code.

So, I basically just copy and paste the code from local production repo directory (minus any git related files) to the staging, then push to the staging the server.

This is lame, and I don't want to do this any more. So, what would be a more efficient set up? Ideally, staging would just 'mirror' production, but we would not want changes made in staging to affect the production.

Upvotes: 0

Views: 296

Answers (3)

UTF-8
UTF-8

Reputation: 625

You can add a git hook on git push to your local production repo which then switches to your local staging repo, pulls from your local production repo, and pushes to the remote staging repo.

Upvotes: 0

Tien
Tien

Reputation: 137

According to what you said, you only need to create 1 repo with two main branches: dev and master. Whenever you want to use the code, for example as you said that :

copy and paste the code from local production repo directory (minus any git related files) to the staging, then push to the staging the server.

Instead, checkout from branch staging to staging-test then git pull --rebase origin master, so the branch staging should be merged with master code.

You can take a look at GitFlow: https://www.atlassian.com/git/tutorials/comparing-workflows

Upvotes: 0

Tim Biegeleisen
Tim Biegeleisen

Reputation: 520878

I don't really know whose idea it was to have two separate repos for staging and production, but I have not seen such a setup very often (or possibly even ever). If you are versioning code for the same product in both repos, then the obvious fix here would be to just use a single repo for everything. You would have staging and production branches in this single repo, and now if you needed to move features from staging to production or vice-versa, you would have things like merging and rebasing at your fingertips.

Upvotes: 2

Related Questions