TFS Build做Web应用持续集成发布的一个技巧

由于面向接口编程的关系,许多实现往往是动态注入运行,在一个项目中直接引用实现dll编译是不合理的。通常我们会在Post Build Event中添加一些xcopy命令将运行时才需要的dll复制到输出目录。在发布时会带来一些问题,比如:使用Visual Studio自带的Publish功能发布一个Web应用时就不会运行Post Build Event。同样的在基于TFS Build时也存在类似问题。

TFS Build时会根据对应Definition的名称创建两个子目录:Source、Binaries,Binaries下针对Web应用会创建发布目录"_PublishedWebsites",如果想要Post Build Event时将dll复制到对应目录下,最简单的方式就是再添加xcopy命令(这样的命令可能有多条),例如:

xcopy /y /i "$(SolutionDir)BuildEvents\Post-build" "$(TargetDir)_PublishedWebsites\$(TargetName)\bin\"

但是会给开发人员带来歧义、工作量并污染Post Build Event。其实我们想做的就是当MSBuild时的某一个参数值符合要求则执行发布用的命令(这个命令和Post Build Event执行的内容一样,就是$(TargetDir)不同),这时就需要修改项目文件来添加一些自定义的脚本实现该功能。首先在Build Definition的高级选项里添加MSBuild Arguments,例如:

/p:RMS=1

由于我的目标是和Release Management Service整合,故使用了该缩写。下面打开项目文件(csproj),开启AfterBuild,并添加一个Exec Task

<Target Name="AfterBuild">
      <Exec Command="$(PostBuildEvent)" Condition=" ‘$(RMS)‘ == ‘1‘ " />
 </Target>

上面的命令实际无法达到最终效果,这里自己绕了一个弯路。主要问题在于对PostBuildEvent的理解,其实它也是一个字符串变量,在执行时它内部使用的$(TargetDir)早已被替换,无法再重新计算结果。例如:

<Target Name="AfterBuild" Condition=" ‘$(RMS)‘ == ‘1‘ ">
    <PropertyGroup>
      <TargetDir>$(TargetDir)_PublishedWebsites\$(TargetName)\bin\</TargetDir>
    </PropertyGroup>
    <Message Text="$(TargetDir)" />
    <Exec Command="$(PostBuildEvent)" />
</Target> 

TargetDir的值确实产生变化,但PostBuildEvent的值也已经被提前计算,我们无法再让它被动态计算一次。幸好MSBuild 4.0以上版本允许我们使用一部分.NET代码来修改这些变量,我们只需调用System.String的Replace方法即可,参考如下:

<Target Name="AfterBuild">
      <Exec Command="$(PostBuildEvent.Replace(&quot;$(TargetDir)&quot;, &quot;$(TargetDir)_PublishedWebsites\$(TargetName)\bin\&quot;))" Condition=" ‘$(RMS)‘ == ‘1‘ " />
</Target>

通过上面的方法就可以将Web应用完整发布,并结合Release Management Service实现持续集成。

时间: 2024-07-30 15:45:15

TFS Build做Web应用持续集成发布的一个技巧的相关文章

(转)Jenkins2.0 Pipeline 插件执行持续集成发布流程

1.Jenkins 2.0 的精髓是 Pipeline as Code Jenkins 2.0 的精髓是 Pipeline as Code,是帮助 Jenkins 实现 CI 到 CD 转变的重要角色.Pipeline是一套运行于 Jenkins 上的工作流框架,将原本独立运行于单个或者多个节点的任务连接起来,实现单个任务难以完成的复杂发布流程.Pipeline 中任何发布流程都可以表述为一段 Groovy 脚本,并且 Jenkins 支持从代码库直接读取脚本. ----------------

jenkins持续集成发布php项目(不需要build)

参考: https://www.cnblogs.com/jimmy-xuli/p/9072015.html 1. 需要安装了 publish ssh插件 2.   配置publisher ssh ,下面的 Remote Directory 可以不用配置.在第3步下面去配置.如果这里配置了.相当于用户会直接进入mnt目录.下面的第3步指定的 Remote Directory会在现在的mnt目录下创建.会形成  /mnt/mnt/test/目录结构. Remote Directory不配置的话会在家

Jenkins+SVN+tomcat持续集成发布

有代码更新后重新打包到tomcat再发布,是不是很烦? 看了下面的东西你就不会烦了. SVN或者git等代码版本控制工具不说了,如果是本地开发,也可以安装一个svn server端 jenkins下载后是一个war包, 首先设置下 环境变量   JENKINS_HOME  为 c:\jenkins 拷贝到一个tomcat的webapp目录下启动tomcat保证能正常访问 http://localhost:8880/jenkins/  多个tomcat请注意修改端口 打开后第一次没任何项目,新建一

Liunx--centos7服务器上 安装 jenkins,实现持续集成发布

1.下载并安装jenkins wget -v https://pkg.jenkins.io/redhat-stable/jenkins-2.176.3-1.1.noarch.rpmrpm -ivh jenkins-2.176.3-1.1.noarch.rpm serivce jenkins start 2.查看初始化密码 cat /var/lib/jenkins/secrets/initialAdminPassword 3.配置基础的插件,必不可少的步骤 登录完成后,系统管理--全局工具配置 配

在TFS持续集成(持续发布)中执行Telnet任务

Telnet是一种在因特网或局域网上使用虚拟终端连接,提供双向交互式文本通信设备的协议. 它是最早的互联网通讯协议之一.自1969年启用以来,已经经过了将近50年时间,在开放式的操作系统中拥有广泛的用户. 虽然由于其安全性的弊端,已经逐渐被淘汰,但是在许多AIX系统的服务器上,运维人员都习惯使用Telnet作为自己的主要工具,维护服务器系统.TFS系统作为应用软件生命周期管理(ALM)平台的产品,原生提供SSH工具连接Linux系统,可惜没有提供Telnet的工具,这里我介绍如何使用Ant中的T

Azure云中Web应用的持续集成实践

由于从事的工作领域关系,目前会或多或少的关注DevOps课题的相关领域,当然目前还在尝试多种适应于持续开发持续集成领域的工具和组合方式,个人粗浅的领会是DevOPS其实既不会只是开发者需要关注的,也是运维人员应该关注的领域,因为未来的IT世界其实是个"相对混合"的空间,发展之快超出想象:在开发测试领域的工具上看,Chef/Puppet/PowerShell DSC,到开源领域广泛应用Salt Stack, Ansible到 Docker生态圈等封装一系列基础架构即代码等概念的涌现,无时

为什么要做持续集成

持续集成在目前大多数的公司里都会有这样或者那样的使用.有的会选择一些Open Source的工具,如CruiseControl,Hudson,LuntBuild等等等等,有的会购买有更好服务,更强功能的商业产品,如TeamCity,QuickBuild等等,而有的会选择自己实现,如Cron+Ant/Maven/Make等等.那么使用下来效果如何呢?真得达到了预期的效果吗?我想来恐怕未必吧,否则也就不会有这么多的讨论了.[@[email protected]] 持续集成与敏捷编程 在敏捷领域中,测

研发协同平台持续集成之Jenkins实践

导读 研发协同平台有两个核心目标,一是提高研发效率 ,二是提高研发质量,要实现这两个核心目标,实现持续集成是关键之一. 什么是持续集成 在<持续集成>一书中,对持续集成的定义如下:持续集成是一种软件开发实践.在持续集成中,团队成员频繁集成他们的工作成果,一般每人每天至少集成一次,也可以多次.每次集成会经过自动构建(包括自动测试)的检验,以尽快发现集成错误.自从在团队中引入这样的实践之后,Martin Fowler发现这种方法可以显著减少集成引起的问题,并可以加快团队合作软件开发的速度. 1.集

【dotnet跨平台】谈一谈dotnet-cli开源社区的产品持续集成

?? [dotnet跨平台]谈一谈dotnet-cli开源社区的产品持续集成 进入其中一个PR:https://github.com/dotnet/cli/pull/2580 可以看到微软使用自己搭建的持续集成平台来保证产品和代码的质量,其中每一个即将整合代码到rel/1.0.0这个主分支的代码都要经过7个测试通过,其中2个windows平台,4个linux平台和一个OS X平台如下: Details Windows_NT x64 Release Build - Build finished.