[开源]TFS与微信企业号的通知整合

直接上地址:

https://github.com/lishewen/TFSWebHook

使用方法:

1、修改web.config中的CorpId/Secret/AgentId,为你自己企业号中申请到的key

2、把站点发布到IIS

3、在TFS 服务挂钩 设置中,选择 Web挂钩 ,并填入URL

http://<host>/api/webhooks/incoming/vsts?code=D854DE27C4ED4A10BFC6BE6E21C3A5A1

如果修改了web.config中对应的code这里也要换成自己的

4、我这里只写了签入代码和git push的事件通知,如果需要其他通知 如工作项变更通知,可自行到Webhooks/VstsWebHookHandler.cs 中添加即可

效果图:

升级.Net Core RC2的那些事(四)——TFS2015的CI集成

这篇应该是这个系列的最后一篇了

配置生成代理

配置dotnet cli环境

这步,需要在生成代理的机器上配置cli环境,与本地配置方法一致,可以自行Google

下载及参考地址:

https://www.microsoft.com/net/core#windows

配置环境变量

在生成代理的机器上

  1. 右键 此电脑 (我的电脑)
  2. 点 属性
  3. 点击 高级系统设置
  4. 点击 环境变量 按钮
  5. 新建 一个新的环境变量 名称为:ASP.NET_Core;值为:RC2;如图
  6. 重启生成代理

确认是否设置成功

  1. 登录TFS
  2. 点击 管理项目 (即 右上方的齿轮)
  3. 点击 DefaultCollection (或者你的其他团队项目名)
  4. 点击 代理队列
  5. 看到 代理 -> 功能中 有刚才设置的RC2,就算成功了,如图

此步,主要是对安装配置过RC2的代理进行区分,让TFS进行CI时能选择到有RC2环境的机器

生成定义

这里我们新建一条生成定义,用 空模板 就好

生成步骤

首先,我们需要通过cli把包还原出来

点击 添加生成步骤,实用工具 -> 命令行

设置项中

工具填:dotnet

参数填:restore

其实相当于命令 dotnet restore

接着,我们需要把nuget的包打包,由于涉及几个项目,我这里使用的是PowerShell

点击 添加生成步骤,实用工具 -> PowerShell

脚本文件名为:RunPack.ps1

内容为:

dotnet pack LSW.Weixin\src\LSW.Weixin -c release
dotnet pack LSW.Weixin\src\LSW.Weixin.MP -c release
dotnet pack LSW.Weixin\src\LSW.Weixin.MP.MvcExtension -c release
dotnet pack LSW.Weixin\src\LSW.Weixin.QY -c release

PS:LSW.Weixin\src\LSW.Weixin 这些是我的项目的存储库相对路径,project.json的对应文件夹,可参照修改。我这里完全是把PowerShell当批处理用了,如果有这方面路过的PowerShell大神看到,有好的建议,还请赐教

然后,需要对ASP.Net Core的项目进行发布,同样

点击 添加生成步骤,实用工具 -> PowerShell

脚本文件名为:RunPublish.ps1

内容为:

dotnet publish 微信企业号\src\分销系统 -r win8-x64 -c release
dotnet publish 微信企业号\src\微信企业号 -c release

同样需要修改对应的路径

这里还需要注意的是,由于项目名存在中文,这里的PowerShell脚本需要用 GBK 编码保存,用 UTF-8 编码的话会乱码报错

最后是添加 复制并发布生成项目 的生成步骤

这个和原来一样就不说了

PS:以上的步骤我没有使用 dotnet build 是因为 dotnet pack 和 dotnet publish 都会执行一次build操作,就没必要加这一步了

存储库设置

选自己对应项目的 Git 分支

常规设置

在常规设置选项卡中,增加一个RC2的需求条件,如图

其他选项

根据自己的喜好设置吧

测试生成定义

设置完成���点击 保存

然后点击 为生成排队 就可以测试一下生成定义了

其他补充

TFS的cli会把一些编译警告,当成错误,导致CI无法顺利通过

这里有两种处理办法

1、按标准修改代码,让警告不出现
2、修改project.json,忽略掉相应的警告,具体位置在 buildOptions 配置节 nowarn 下
	"buildOptions": {
		"emitEntryPoint": true,
		"preserveCompilationContext": true,
		"nowarn": [ "CS0168", "CS0169", "CS1998" ]
	},
CI完成后的自动发布Azure、FTP什么的这些没改,可以参考其他文章进行配置

让TFS忽略packages文件夹的更改

很多时候我们需要使用 Nuget 进行包管理,这时在我们的解决方案文件夹下便会产生一个名为 package 的文件夹

由于 Nuget 包经常要更新,TFS 会自动把这些包放到 正在挂起的更改 处,这对于强迫症十分不友好(这里面明明不是我写的东西Baring teeth smile

于是,这里提供两种方法让 VS 不监视 签入,package 的更新

1、在 团队资源管理器 –> 正在挂起更改 –> 包含的更改 –> 视图选项 –> 勾上 显示解决方案的更改

2、在解决方案的文件夹下,新建一个文本文件,名为 .tfignore

内容为

\packages

如果需要更复杂的配置,可以参考以下信息修改:

################################################################################
#
# 此文件中与 filespecs 匹配的本地项将不会添加到版本
# 控制中。可签入此文件以便与其他人共享排除内容。
#
# 通配符为 * 和 ?。模式以递归方式匹配,除非
# 该模式使用了 \ 字符作为前缀。
#
# 你可以在模式前面放置路径以使其更加明确。如果添加路径,
# 则在路径部分不允许使用通配符。
#
# 行首的 # 字符指示该行是一条注释。
#
# ! 前缀将使模式无效。在某个项由树中更高级别
# 的 .tfignore 文件或团队项目集合的全局排除列表排除之后,
# 可以使用此前缀来重新包括该项。
#
# / 字符在 Windows 平台上被解释为 \ 字符。
#
# 示例:
#
#  # 排除 Alpha\Beta 及其所有子文件夹中以 .txt 结尾的所有文件。
#  Alpha\Beta\*.txt
#
#  # 仅排除此文件夹中以 .cpp 结尾的所有文件。
#  \*.cpp
#
#  # 排除此文件夹及其所有子文件夹中以 .cpp 结尾的所有文件。
#  *.cpp
#
#  # 如果“Contoso”是文件夹,则排除 Contoso 及其所有子项。
#  # 如果它是文件,则仅排除此文件夹中的“Contoso”。
#  \Contoso
#
#  # 如果 Help.exe 已由更高级别的 .tfignore 文件或团队项目
#  # 集合的全局排除列表排除,则此模式仅在此文件夹
#  # 中重新包括它。
#  !\Help.exe     #
################################################################################

使用TFS2015生成并测试ASP.Net Core项目

在TFS上配置ASP.Net Core所需的DNX环境

这里通过PowerShell实现,在解决方案中增加一个PowerShell脚本,这里名为 Prebuild.ps1

# bootstrap DNVM into this session.
&{$Branch='dev';iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/aspnet/Home/dev/dnvminstall.ps1'))}

# load up the global.json so we can find the DNX version
$globalJson = Get-Content -Path $PSScriptRoot\global.json -Raw -ErrorAction Ignore | ConvertFrom-Json -ErrorAction Ignore

if($globalJson)
{
    $dnxVersion = $globalJson.sdk.version
}
else
{
    Write-Warning "Unable to locate global.json to determine using 'latest'"
    $dnxVersion = "latest"
}

# install DNX
# only installs the default (x86, clr) runtime of the framework.
# If you need additional architectures or runtimes you should add additional calls
# ex: & $env:USERPROFILE\.dnx\bin\dnvm install $dnxVersion -r coreclr
& $env:USERPROFILE\.dnx\bin\dnvm install $dnxVersion -Persistent

 # run DNU restore on all project.json files in the src folder including 2>1 to redirect stderr to stdout for badly behaved tools
Get-ChildItem -Path $PSScriptRoot\分销系统 -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 }
Get-ChildItem -Path $PSScriptRoot\MVC6.UnitTest -Filter project.json -Recurse | ForEach-Object { & dnu restore $_.FullName 2>1 }

其中 分销系统 和 MVC6.UnitTest 为我测试的项目,即project.json所在的位置,请自行修改为自己对应的项目

然后登录TFS修改生成定义,添加一个PowerShell的生成步骤,把脚本文件指向 Prebuild.ps1

如果你在TFS上找不到这个文件,请先把这个文件签入TFS

添加XUnit项目

如果你的VS中有XUnit的模板,直接添加就可以了。如果没有,可以先创建一个ASP.Net Core Class Library的项目,然后参照下面的 project.json 内容,来添加xunit package的引用

{
	"version": "1.0.0-*",
	"description": "MVC6.UnitTest Class Library",
	"authors": [ "lishewen" ],
	"tags": [ "" ],
	"projectUrl": "",
	"licenseUrl": "",
	"frameworks": {
		"dnx451": {
			"dependencies": {
				"xunit.runner.visualstudio": "2.1.0"
			}
		},
		"dnxcore50": {
			"dependencies": {
				"Microsoft.CSharp": "4.0.1-beta-23516",
				"System.Collections": "4.0.11-beta-23516",
				"System.Linq": "4.0.1-beta-23516",
				"System.Runtime": "4.0.21-beta-23516",
				"System.Threading": "4.0.11-beta-23516"
			}
		}
	},
	"dependencies": {
		"xunit": "2.1.0-*",
		"xunit.runner.dnx": "2.1.0-*"
	},
	"commands": {
		"test": "xunit.runner.dnx"
	}
}

在单元测试中添加一个简单的测试方法

		[Fact]
		public void PassingTestDnx()
		{
			Assert.Equal(1, 1);
		}

写一个运行xunit单元测试的PowerShell脚本,RunDnxTest.ps1

Set-ExecutionPolicy unrestricted -Scope CurrentUser -Force
dnx -p $PSScriptRoot\MVC6.UnitTest test -xml $PSScriptRoot\MVC6.UnitTest\testresults.xml

最后参照 Prebuild.ps1的步骤,在生成定义中,再加一项PowerShell的生成步骤,并指向脚本 RunDnxTest.ps1

此步骤完成后,我们还需要添加一项 发布测试结果 的步骤,已便将XUint的结果与原来Visual Studio 的单元测试结果合并

具体参照下图配置:

至此,ASP.Net Core的自动生成和测试的配置就完成了,我们可以运行下生成定义来看看测试结果

TFS2013升级Update 2错误 - TFS255440

TF255440: The following account has a SQL Server login, but the login was denied access: lsw\lishewen. The server selected to host the databases for Team Foundation Server is: lswserver. The SQL Server login associated with the user account must be granted access to the SQL Server instance on that server.

解决方法:

首先将你的账号加入sqlserver管理员组(如果是,则不用加)

如security\logins下添加账号   赋予systemadmin,serveradmin权限

TFS新建团队项目模板差异

在搭建好的TFS server中,我们新建了团队项目集之后,需要在团队资源管理器中(VS10版本)新建团队项目,在向导中有:选择过程模板

clip_image001

这两个过程模板可以用于定义计划和跟踪项目的工作项,报表和面板集。

两者的不同在于:

如果团队使用SCRUM或者其他敏捷过程,选择MSF for Agile

如果团队需要严格的审计记录并对变更管理使用正式过程,选择MSF for CMMI。

两者的主要差异:

工作流状态:

· 当团队通过将工作项的状态从活动更改为已解决直至已关闭来记录多数工作的进度时,请选择 MSF for Agile。 团队会创建一个处于活动状态的工作项,并在完成工作后解决该工作项。

· 当团队通过将工作项的状态从已建议更改为活动、已解决直至已关闭来记录多数工作的进度时,请选择 MSF for CMMI。 团队会创建一个处于已建议状态的工作项,并且只有在已接受该工作项后,才会将其转为活动状态。

MSF for Agile的活动状态有:活动,已建议,已解决。

MSF for CMMI的活动状态有:已建议,活动,已解决,已关闭。

产品计划:

· 如果围绕用户情景和情景点来计划产品,请选择 MSF for Agile。

· 如果基于要求和更改请求来计划产品,请选择 MSF for CMMI。

迭代挤压工作管理:

· MSF for Agile 提供了“迭代积压工作”工作簿,该工作簿可用于计划迭代。

Bug积压工作管理:

· MSF for CMMI 提供了用于跟踪症状和建议的修复方案的附加字段。

项目管理:

· 使用 MSF for Agile,团队可以通过创建问题工作项来跟踪团队项目的已知或潜在的问题、障碍或风险。

· 使用 MSF for CMMI,团队可以通过创建问题或风险工作项来跟踪团队项目的已知或潜在的问题、障碍或风险。 此外,还可以使用评审工作项正式跟踪代码评审。

测试管理:

· 为测试用例跟踪的信息对于这两种 MSF 过程模板基本相同。

· 测试管理报表对于这两种 MSF 过程模板基本相同。

审核记录:

· 当不要求团队支持严格审核时,请选择 MSF for Agile。

· 当要求团队维护严格的审核记录或致力于能力成熟度模型集成 (CMMI) 认证时,请选择 MSF for CMMI。

微软宣布TFS云服务

微软在Visual Studio Live上宣布Team Foundation Service(TFS)将增加一个基于云的构建服务。 TFS目前支持分布式构建,但每个用于构建的虚拟机必须分别设置和配置,基于云的构建服务将可以自动化这一过程。

预览版现阶段支持Visual Studio 2010和 Visual Studio 11 beta的C++ 和.NET应用的构建和单元测试,下一阶段将支持Java构建。基于云的构建系统的一大卖点是易于扩展,可以根据需要增加虚拟机实例。微软还宣布 Visual Studio Ultimate 11生命周期中将发布多个功能包。