Check .NET versions installed

There are several ways to find out which versions of .NET are installed on your system or on a server.  Below are a few Powershell commands Ive been using.

<#
Version                 Minimum value of the Release DWORD
.NET Framework 4.5         378389
.NET Framework 4.5.1     378675
.NET Framework 4.5.2     379893
.NET Framework 4.6         93295
.NET Framework 4.6.1     394254
.NET Framework 4.6.2     394802
.NET Framework 4.7         460798
.NET Framework 4.7.1     461308
#>


#-- Find out if specific version of.NET Framework installed
Get-ChildItem "HKLM:SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\" | Get-ItemPropertyValue -Name Release | ForEach-Object { $_ -ge 378389 }




# -- Check for .NET Core 2.0
$software = "Microsoft .NET Core Runtime - 2.0.0 (x64)";
$installed = (Get-ItemProperty HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\* | Where { $_.DisplayName -eq $software }) -ne $null

If(-Not $installed) {
 Write-Host "'$software' NOT is installed.";
} else {
 Write-Host "'$software' is installed."
}
 

VSTS and Build process

Overview 

Visual Studio Team Services VSTS offers in one platform, what took several tools to accomplish – SVN, TeamCity, Teamwork, Kanban, Youtrack.  It will be a learning curve instead of a single event.  One of the challenges will be understanding the new vocabulary.   

For starters: 

A team project is a container for a portfolio of related applications. A team project can contain one or more source code repositories(Git/TFVC), builds, releases, test cases, work items, etc. All of these entities have ways of defining security around who can view/modify them. 

A team is just an organizational structure within a team project. You can use security permissions to limit certain repos, builds (or build folders), etc to a certain team.  

The generally accepted guidance is to keep everything in a single team project. There are lots of things that don't cross team project boundaries, such as repos. Work-arounds usually exist, but they are typically awkward.  

Common approach 

• One Team project with multiple teams and Git repos. 
• Each team has a backlog of work items and/or tasks 
• The Team project (misleading term) is a collection of related applications 

Quick Run through, from Build to Release

See here

Git branching strategy 

The master branch should be kept "production ready" at all times.  New efforts create branches from here 

When work on a feature branch is ready to be tested, the changes can be merged to the Dev branch when ready to test. A CI build definition will need to have an existing branch to pull from for each consecutive build cycle.  So this is the reason for an extra branch in the image below.  The build can be triggered from the Dev branch, with any errors letting the committer know early if there was an issue eg – a missing dependency that wasn't committed into source control. 

There are several different "patterns" or strategies for how to create and manage branches.  There is Git flow, Github flow and a few others.  Some more involved than others.  It depends on your environment and other factors.  Read this overview for more info.  Some refer to this strategy as an environment branching strategy. 

Git branch naming conventions 

git branch naming convention 

[author]-[shortdatetime string]-[short-description] 

eg.  bsmith-05082017-newwidgetthingy

Separate spaces with dash 

Git workflow – our version "The Pipe"  

Everything goes down the pipe by starting at one end, down the pipe and out the other end. No, stopping half way, drill a hole and exit out the side, or stay in the pipe and block other things. 

As mentioned above with the Git flow branching strategy, the typical "workflow" one would perform is explained in the VSTS documentation here. A more common scenario involves different "environments" such as development, testing and production etc.  

(1) Create a branch from master, for the changes your working on (see naming conventions above) 

(2) Commit changes to this local branch.  Rinse and repeat – work, commit updates 

(3) Push changes to remote when ready to share.  If others are working on this branch, you will need to occasionally do a Pull request to see what has changed, then do a Fetch and merge. === when ready to test on dev ===== 

(4) When ready to test on a development server, commit and push your changes to your remote repo, merge to the "Dev" branch (do this through VS Team Explorer) 

(5) Queue a dev build.  This will pull code from the dev branch where you just merged changes to.  If all goes well, the changes will be deployed.  If there are build issues such as missing items, the team will be notified. This removes the gap between someone checking in changes thinking they are done, and problems that show up later when trying to build to dev. ===== going to production ===== 

(6) Finally, when everything is ready to be released, merge back to the master branch.  We can also do this via a pull request, but its not required but it gives us a chance to review the changes with others. 

(7) With changes merged back to master we can now build to prod.  This build will pull from the master branch. After the prod build completes and there are no issues, we can now delete our feature branch.  If a bug is discovered, we should create a new feature branch and repeat the steps above. 

The "What-if" scenarios 

Production bug fix – While working on a feature branch, a production bug fix is needed.  Handle this by creating a "bugfix branch", from master.  Make the updates in this branch, push back through dev, test and then merge back to master and then build prod.  Then merge the "bugfix" changes back into your feature branch and continue as before. 

On-premises build 

Since VSTS is a cloud platform, there has to be a path for deploying the builds to a target.  If this target is on premises, then additional steps are needed to make this happen.  Services known as a build agent are configured to relay between VSTS and the target server.  Below is an overview.  For more on this, review these links (1) https://blogs.msdn.microsoft.com/devops/2017/04/10/deploying-to-on-premises-environments-with-visual-studio-team-services-or-team-foundation-server/ 

(2) https://docs.microsoft.com/en-us/vsts/build-release/concepts/agents/agents?view=vsts 

Overview – the horizontal line, typically being a network firewall. 
Communication occurs over port 443 (https)