TFS Landing process in the project (top)

As a developer, after nearly 2 years of tossing, the DevOps mainline project based on TFS has largely landed.
In this general memory of the middle of the various processes.

Before you start, simply say what is TFS (Team Foundation Server).

TFS is an ALM (Application Lifecycle Management) management tool introduced by Microsoft.

With TFS, you'll get a family bucket feature that includes a series of software lifecycles, such as auto-launch, automatic release, and automated testing, from code versioning, project management, and continuous integration, as well as a cloud version called VSTS.

Vsts/tfs=github+trello/teambition/tower/jira/rally/rtc+qc/testlink+jenkins.

TFS is not just a store of code,

TFS is not just a store of code ,

TFS is not just a store of code,

Important thing to say three times. The only use of TFS to store the code is the equivalent of 6000 dollars to buy an iphone in front of the 200-block Nokia function machine in use, throwaway.

This article will say : TFS in our group to enhance the role of our group DEVOP and various processes.

This article will not say : How to configure TFS specifically.

Hopefully this article will help you with a team or individual who is using TFS or wants to use TFS.

The No. 0 chapter--History

Just arrived at the company, that year is 2015, as a development of small white I just joined the war.

At this time the company is based on TFS2010 using TFVC for code management, project management based on Jira, no automatic packaging/publishing, no automated testing.

First, as an aspiring youth, in this SVN-represented centralized code management has been declining and git thriving era, and SVN same strain TFVC nature is dismissive.

And it uses the TFS2010 5 years ago ... That interface:

Don't want to use it at a glance. The UI is completely out of step with the times.

And the TFS2015 of the same period:

Significantly more modern, more user Experience.

Then the code was managed using the Git in VSTS (then called Visual Studio Online), which was not a rule for us, but on the one hand it was the new project (the kind that started the new project), and the other was just a temporary solution.

Of course, at the same time to apply to the boss, see if you can get a TFS2015 ... After all, keep abreast of the times.

The 1th chapter--Promoting Git

Behind in the eldest brother's assistance, finally got our own TFS2015, then of course the first step to the original VSTS code in the past, and then their own based on the above happy coding.

Subsequent other projects are then gradually migrated to the new TFS server.

Because the new project collection is based on Git for code versioning, there are several issues:

① how to persuade other colleagues who are accustomed to the TFVC workflow to use git;

② How to do code control on Git.

Before you say this question, let's talk about why I like to use git myself:

First of all I think in the technology selection must avoid because this is the most popular/latest so I'm going to use it for this kind of metaphysics, we want to use a product, we must understand what it is, and it is to solve what problem was born, only in this way can choose the right product (note: is appropriate, not " Best ").

I personally is a BYOD (bring equipment to work), on the one hand is the objective of the company's computer battle slag (at least now after the upgrade or mechanical disk, my main Microsoft Pro Son 4 is a full-solid state), on the other hand by the idea of BYOD to brainwashed, on the other hand can be convenient anywhere add a class ...

Git's offline submission is a pretty powerful feature for me.

In addition to the centralized control of each commit to do a different strategy, I personally prefer to submit each time without any policy check, but in the pull request phase in the policy of "packaged code control."

The other is the Git branch, which makes branching a feature that's easy to do.

For these reasons, I chose git.

Then is the original colleague's "The Law of the Law", one of the more headache problem is git commit and push these 2 concepts are often not clear, although now I can not be able to say, after all, TFVC when the point of submission is really on the server, and now you "submit" did not count, but also in sync ( Sync) or push (push) to do it.

In addition, pull request is enabled to manage code that needs to be developed/published, but it is also a preliminary introduction to the concept of "code review": Each pull request requires at least one person to agree with it:

Then, because Git branches are especially handy to use, it's easier to co-develop later, because each is independently developed in its own branch.

And since then, each time we publish, we'll pull a branch out of the release date as a backup branch to do the processing needed for the various temporary updates:

Phase summary, as the introduction of Git brings us:

① more convenient for everyone to cooperate in the development, now everyone has their own development branch to develop their own responsible functions;

② more convenient to pull the backup branch, since our group in dealing with this matter more comfortable;

③ introduces pull request and the most original code review.

2nd-Introduction of initial auto-release

From the history of the No. 0 chapter has been written that we do not have any automatic release of tools or routines, one of our regular release process is: first developed, and then with the "right-click->publish" to generate a release package (folder), and then submitted to SVN, The colleague who informs QA is updated to the test environment by taking the package.

First of all, the process is tedious and wasteful, followed by frequent mistakes, and sometimes a vicious problem such as a person's code not being merged, whether it's our development team or QA group that's miserable, and automatically releases the prioritized schedule.

The idea of the initial release of the auto release is simply to automate the "right-click->publish" in vs.

First we know that the publish of VS is available to support publishing to remote servers:

I just need to fill in the target server's shared folder address at Target location and my server has access to the target server, then it can be published directly:

The corresponding MS build parameter in the build solution step in TFS can be automated by simply filling in the corresponding configuration file for the release.

But the package has the following issues:

① the released machine must have a shared folder configuration;

②build Agent to the published machine must have access to the corresponding shared folder permissions (to be prepared beforehand);

③ each release is actually from the code base to drag out the code and then recompile, if the version is different than the DLL version of each environment is mismatched. (At least the file creation time is definitely different).

This led to the configuration of the set to be released by the machine and buildagent at the same time to do a different degree of configuration, and this obvious to the later, regardless of the increase in buildagent or the release of the server is not a good thing, but after all, the first step, there is better than no, first to say.

The other point is that we are normal practice is to commit the code is not with the DLL, so now the local reference DLL in the form of automatic release is very easy to issue (do not tell me to commit the DLL into version control).

So, for the first time, we introduced NuGet as a must-have, but before that, NuGet was a way to use it and not to use it in a local DLL.

Because of the need for automatic publishing, we no longer allow local reference DLLs and require that all external dependencies be managed through the NuGet server.

At the same time, the QA team also commented on the process, asking them to agree on a test environment before they could say what time they wanted (or I would configure a trigger for continuous integration).

So we introduced the concept of QA branch in new.

QA Branch Only a colleague of the QA Group has audit access to pull request, such as this configuration:

The QA branch automatically triggers the demo environment (the first test environment) for automatic publishing (implemented via trigger), and the subsequent testing environment and pre-release environment will only be based on the code of the QA branch.

Then, for a period of time, there was a significant reduction in issues with the release of the automatically released items, and the time required for QA colleagues to spend on the update package to the test environment was significantly reduced.

Phase Summary:

① introduced the automatic release;

② introduced the QA branch and clarified the process on the release;

③ the use of NuGet as the only option to reference external DLLs, unifying externally dependent management.

3rd. Automatic release optimization

At this point, Microsoft released Tfs2015update2, the relevant updates can refer to the Tfs2015update2 update log.

The most important of these are:

Introduced the Release management function, formerly this is as a standalone product now as a sub-function integrated into the TFS, and then in our boss to help let operations beyond the upgrade TFS to Update2, we started how to let us also use "Release" The function.

Another point is that this version begins with TFS, which has its own store, and has been on the road to a variety of extensions.

First I understand that the release and the original build should look like this:

By building the code into a DLL, then find a place to save it, and then release to the environment through release, because release is only to act as a "copy dll+ configuration" function, and the DLL is the original build, So DLLs in each environment should be the same.

Then the steps of a typical build that have been adjusted (by deleting the ones that are not left only necessary) are this:

Then the release steps are probably like this:

Here will not detail the above meaning, specific configuration can refer to Microsoft Official document build for ASP and Deploy to Windows VM

By now our automatic release has become something like this:

Notice the middle grid, Gray indicates that the corresponding environment did not perform the release action, and the Green is published and published successfully, corresponding to the yellow (published but partially successful) and red (publishing failed).

And then the project release process reached the stage at which we can now glance at it and not always go and ask QA: "Where has it been posted, testing?" ”。

Not long after this automatic release, I was surprised to find that the "IIS Web App Deployment" task in release had something like this:

Although my English is not good, but between the lines vaguely guessed it should be possible to replace some parameters during deployment (guess the same as the transform vs release).

In the past, we had to exclude web. config from being published, because it is like a database link string, which is different in every environment, and then it is ready for each environment Web. config, and it is not published in such a way as Web. config.

The problem is that we often update the NuGet package when it is actually moving the Web. config, and then this change each time in the SVN package write a txt to tell QA how to change (can you imagine the QA in a bunch of XML to find the node you need and then do the pain of corresponding changes?) ）。

Like this:

Behind the OPS, the "Environment-related" Web. config file is extracted as a non-updated part, and the Web. config is updated every time as part of the release, and the split of the roughly split Web. config can be referenced using the ConfigSource feature split Web. config file

But I always think that this kind of thing should be more "automated" solution, and if a document is not released in the long run, who would have thought of it if it had really changed? Then go to the "Web Deploy Parameter File".

It is found that as soon as you specify an XML file and then during the IIS deployment phase, Web deploy will replace all the specified profiles in your site with the corresponding configuration file (yes, all, not limited to Web. config).

Its file definition is probably like this:

Back to use after the feedback is good, since then we developed the Web. config is also published as a publishing file, and then each time the release of the file in the deployment phase automatically converted into the database link string or some appsetting.

Since this project has been done, basically did not pass a txt form to tell QA how to change the configuration file.

Phase Summary:

① upgraded TFS to get Release management functionality and support store functionality;

② will automatically publish split the build and release two steps, more standardized automatic release process;

③ through release we develop to be able to know clearly now the test to what stage;

④web.config is configured to automate the distribution of delegates.

Big Summary

Experienced the above-mentioned toss, now we basically from the feudal era stage into the Industrial Revolution era, the introduction of git (especially its branch function), the introduction of automated publishing.

The whole let our group into the stage of initial modernization.

We'll talk about how we do code analysis, integrated Monitoring, netcore support, etc. based on TFS.

TFS Landing process in the project (top)