How to perform the version control of the application in production?

2

When using TFS , we have all version control of an application's files.

So, with each modification of files, by countless members of a team, each file will have its version ...

An example that can happen ...

It was developed the development of some functionalities, and was sent into production ... Meanwhile, several other functionalities have been developed, which are independent and also that if communication with existing functionalities ... If these new features are sent to production, and there is a "big" error, how do I go back to the stable version?

So, I would like to know how to control the version that was compiled for production, in case there is a drastic problem, get back to the stable stable version?

    
asked by anonymous 23.10.2015 / 16:40

1 answer

3

Your question is old here, at the time the solution was different, but today a lot has evolved, and I believe it can help others who may be in the same situation.

TFS (Team Foundation Server) is a tool that goes beyond simple version control of applications, TFS is a complete stack of DevOps from Microsoft.

We can say today that TFS has "two versions" :

  • On-Premisses: TFS, which you install on your network, you manage bkp, update, etc.
  • Cloud: VSTS (Visual Studio Team Services), you do not have to worry about installation, configuration, bkp, update, etc.

TFS / VSTS has a number of features that, if well used, allow you to perform this version mapping, as @Rod was looking for, it's these features:

  • Versioning, using GIT and / or TFVC repositories
  • Agile Planning, for task management, Scrum, Kanban
  • Build Automated, to validate if the project is ok, and generate the packages for deployment
  • Automated Deployment, to deploy the application in all environments, with approval cycle, scheduling, etc.
  • Well, now to the point of the question.

    Because VSTS / TFS has automated deployment functionality, you can validate which version of the build was deployed in the last time environment, so doing deployment with that version re-specifies the environment.

    About the first image: This is the Deployments Dashboard, each green box, it refers to an environment where Deployment was performed, the part where the build is made, is the version of the build that was used in deploy, so in case you need to go back to the version, you can see which build was deploy, and thus start a new one using this build to ensure that the functional version is in production.

        
    04.07.2017 / 18:44