Is using version control on the production server a good practice?

Question

In the company where I work today, we have a Web system (C# ASP.NET) where we use the Team Foundation Server 2013 in the development environment. On the production server we don’t use any version control: we only use FTP, but today a debate has arisen here about how we know who put a code in the production environment or who modified it.

I wonder if putting version control on the production server is a good practice and with a single repository that contains the production and development environment.

Updating

My goal is: when I upload some modification to the server, which is not via FTP, but via version control so that there is history of the modifications made in production environment.

Answer 1

My answer will be given independently of development technology.

Your essential question is:

"How do we know who put a code in the production environment?"

Ideally, the system running in the production environment is a closed version, well defined and uniquely identifiable through (at least) a version code such as "v.1.0.0". This type of identification exists essentially to allow administrators to know exactly what is running on the server in terms of the implemented functionalities.

If your project uses a version control in the right way, your work process is briefly as follows::

1. Developers work on fixing issues and implementing news arising from specific requests, usually identified by "ticket" numbers in a change control system (which may or may not be integrated into the version control system). Changes to the code are made in a way that is traceable to those requests. For example, when doing commits in Git, developers can indicate in the comment what is the number of the ticket the changes relate to.
2. Someone in charge of the team plans the next version (e.g., v.1.0.1) in terms of what fixes and news will be delivered. This person charges developers for implementing the code and integrators for regression testing, and eventually demands the production (compilation) of the new version, which will include only planned changes. This is all done outside the production server, because it can be done while the current system is running and serving customers.
3. After the new version is generated, it is updated on the production server (at some point in time, for example during the night when the use of the system is less and the interruption to update will generate less inconvenience). From the identification of the version (v.1.0.1) and the traceability matrix provided by the tools used and, mainly, by the process (where problems are described by a specific ticket and developers always remember to indicate such tickets in commit comments), it is easy to identify which changes were added (and who made them) to the new system running on the production server. Even more important than that, in case regressions, it is easier to identify the cause.

In short, you only know who put something on the production server if you have the history of updates made and future updates are made independently of what is running today.

Using version control on the server is not an issue per se as long as the areas with which it runs and what is being developed are kept separate. Otherwise, what is running (assuming something is interpreted) will be constantly changed and you simply lose control of what features are in use. But from a performance and security point of view, it doesn’t seem like a good idea to use the same server for both tasks. The same machine will be dividing resources to the final client and to the developers, and any need for downtime (to update its version control software, for example) will impact the availability of the service to customers.

If you don’t use any version control system (FTP only, as you say), it’s even more important to keep the structures separate for you to have at least some manual control of which features will be running. At some point, someone responsible will need to stop coding activities to "group" the code into an identifiable version and put it on the production server.

Answer 2

As Luiz Vieira put it well, you already have history and version control, in your production environment you are not running code, you are running binaries.

TFS must be unique, its version control must be unique.

What you have to worry about is what is running in each environment and you do it from the build. It is in the build that you will tie the binary version, which will lead you to the changes in the code, to your requirements, etc.

And to promote the build between environments today Microsoft has a deployment automation solution called Release Management. How it promotes the binaries and will have a history of what is running in the environment.