How to deal with other teams working directly in the production environment?
The current setup is as follows.
- Git branch strategy for feature branch model without a develop branch
- Using git with Doxygen FILE_VERSION_FILTER
- pushing to a git repository does not work
- How to integrate a local repository with current unity project?
- Does the squashing commits deletes individual commits from other branches as well
- Version control for version control?
Devs within my team work in their own environments, using their own branches. They merge upstream to a testing environment. Occasionally, the testing branch gets merged upstream to a user acceptance branch in its own environment. This, in turn, gets merged upstream occasionally to the production environment, which is our master branch.
The problem comes from the existence of other teams that we don’t have any authority over:
The other teams will not use our repository, and they will make relatively frequent changes in the user acceptance environment, and sometimes even in the production environment.
What is a good strategy to deal with this problem?
Should we do automatic (daily) pushes from the production/UA environments into their respective branches? If so, how do we deal with conflicts that might arise? Are there better solutions?
I apologize if this question has been asked before but I did my best to find an answer here and elsewhere, without success. I have read many resources on version control strategies but they all seem to make the basic assumption that other teams will use the same repository, and will not make changes in the production environment directly, but use version control to merge upstream to the master branch.
2 Solutions collect form web for “How to deal with other teams working directly in the production environment?”
If you really can’t make them use a version control system, the only solution I can think of is to write a script (running on the production environment) that will commit and push their code periodically. At least, you will be able to pull it for your team in order to merge it before pushing your own code.
That is NOT clean. At all. But you seem to be very desperate, and I guess you can’t just get rid of them.
I usually won’t recommend this, but since you have limited options, if you can, then just install git on all the non-development environment. Then every time when someone manually patch it, you can use git status to identify the differences, and decide what you want to do from there i.e. commit, push, revert, format-patch etc.
I find it hard to believe there are still people (whole teams??) who don’t use version control, and commit changes directly to production environment these days. How would the other teams know whether their changes have been tested and reviewed, and remain compatible with what everyone else is doing? I, personally, won’t condone this type of anti-pattern, left alone changing my team’s workflow to accommodate them.
Here are some of the things I will do:
- Talk to your boss and their boss regarding the risks (and the cost) that these type of untested, unverified, untrackable, and non-repeatable changes will incur.
- Lock down direct access to all non-development environment. No one should have direct access to any non-development environment. You’re not using SFTP to do your deployment, are you? 🙂
- Use tools like puppet, chef etc. to automate your deployment process.
- Enforce the “automatic revert” policies that these tools provide, where any non-version-controlled manual changes applied to the environment will be merciless reverted.
- Teach the other teams the benefits and techniques of using version control. Alternately, just fire them 🙂