How to manage approval and production environments with Team Services?

9

I'm in an ASP.Net C # project that is starting now, but I come from ASP Classic , where things are quite different.

In this new project, we need to create and manage homologation and production environments, where changes must go to the homologation environment, tested by another team, and then approved, go to the production server.

The way we did this in Classic ASP was simply to have two domains, with distinct FTP, and after passing the approval environment, we copied the files from one FTP to the other so that available in production.

In .Net I was introduced to Team Services , but I confess that I still have not figured out exactly how it works and if it can help me with this seemingly simple problem.

My question is: How does Team Services work and how could it help me with this version control and environment?

    
asked by anonymous 23.06.2016 / 22:22

2 answers

8

The best introduction is this one .

In projects that use Git, a good practice that is becoming common is not to accomplish commits and pushes in branch master : this branch is usually used for continuous integration, that is, every time new code is sent or merged in master, there is a feature that can be activated for that the project be tested and published alone.

For teams, create branches that represent or workflows in>, etc.) or new features ("resource-name-new1", "old-resource-refactored2", etc.). When the functionalities are completed, the merge is done for master and, depending on the configuration, the integration service continues to go up the project to a test instance or even production.

TFS has the same feature .

In addition, there are a number of tools offered that are inherent in a project's development effort, such as Backlog, productivity tools, and integration with other cloud services.

With this, the idea of using FTP is simply out of date. For example, in an ASP.NET MVC project with Entity Framework, updating the database is done automatically by a process called Web Deploy , which also has the function of publishing the code on the application server.

    
23.06.2016 / 22:28
3

Completing Gypsy Morrison's response,

To manage and deploy multiple environments you can use Release Management link

Here we work as Cigano commented, we have a master branch where we have a Build Definition with a trigger pointing to this master branch. Every checkin that is done in this branch is the trigger for queuing a build. At the end of the build, the team receives an email notification.

AndwealsohaveaReleaseDefinitionwherethetriggerisjustourBuildDefinition.Eachsuccessfulbuildistriggeredbyourrelease,whichisverysimple,onlypublishingtheapplicationontheserver.

But with Release management you can configure much more detail like publishing in various environments, waiting for approval, and being approved are published in the next environment. For example, publish in an approval environment, when it is approved for a pre-production environment, when it is approved, publish in production.

You can also run various processes such as testing or even running local commands on servers for environment adjustments.

    
18.10.2016 / 22:32