How to perform version control of the application in production?

Asked

Viewed 217 times

2

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

Then, with each file modification by numerous team members, each file will have its version...

A example that can happen...

It was carried out the development of some functionalities, e foi mandado em produção... Meanwhile, several other functionalities have been developed, which are independent and also communicate with existing functionalities... If these new features are sent to production, and some "big" error occurs, how do I go back to stable version ?

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

  • There is no binary code version control, only from the source. For this just copy the previous version of the executable. In general you have somewhere. If not, go back to the source and Compile it. Of course if you have to go back database structure complicates a little and in some cases it becomes unfeasible to go back (you can always make it possible, but you need planning).

  • TFS is just a tool for controlling changes. TFS can use the same concepts applied to GIT or SVN. It also has Branching, Merging and Labeling. The latter is equivalent to tagging in Git. I don’t use TFS so I won’t give it as an answer, just a direction.

  • Continuing... As @bigown said, the final executable is not versioned. Assuming that the implementation only exists after the application has been approved, if there is a serious error, a new version is required and not a previous one, but if you still need to go back, the steps to this should be documented in the deployment process as the rollback of implantation.

1 answer

3

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

The TFS (Team Foundation Server), is a tool that goes beyond the simple control of application versions, the TFS is a very complete Stack of Microsoft Devops.

We can say today, that the TFS possesses "two versions":

  • On-Premises: TFS, which you install on your network, you manage bkp, update, etc
  • Cloud: VSTS (Visual Studio Team Services), which you don’t need to worry about installation, configuration, bkp, update, etc.

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

  1. Versioning, using GIT and/or TFVC repositories
  2. Agile Task Management Planning, Scrum, Kanban
  3. Automated Build, to validate whether the project is ok, and generate packages for deployment
  4. Automated deployment, to deploy the application in all environments, with approval cycle, scheduling, etc.

Well, now back to the question.

Since VSTS/TFS has an automated Deployment-oriented functionality, you can validate which version of the build was implemented in the environment last time, and thus perform the Deployment with this specific version again in the environment.print do Release Management

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

Browser other questions tagged

You are not signed in. Login or sign up in order to post.