How to deal with other teams working directly in the production environment?

I work for a team in a large company, tasked with setting up continuous integration for them. The problem is: how do I deal with other teams that work directly in the production environment?

The current setup is as follows.

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.

  • How does the git's “local-repository” concept differ from “developer branches”?
  • One of similar files in Git repo disappeared after copy
  • In git how to diff microsoft word documents?
  • Alternative to phpUnderControl - is it the best?
  • How can I run “git status” and just get the filenames
  • App Icon not changing when app version is updated in iOS 5 simulator
  • Differences Between Fixup and Removing a Commit in Git Rebase
  • How should I organize source control for Android projects including libraries?
  • 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:

    1. 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.
    2. 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? 🙂
    3. Use tools like puppet, chef etc. to automate your deployment process.
    4. Enforce the “automatic revert” policies that these tools provide, where any non-version-controlled manual changes applied to the environment will be merciless reverted.
    5. Teach the other teams the benefits and techniques of using version control. Alternately, just fire them 🙂
    Git Baby is a git and github fan, let's start git clone.