精华内容
下载资源
问答
  • 毕业设计论文 题 目: 基于Java EE仓库管理系统 成全部电子机械高等专科学校 二八年六月 论 文 摘 要 伴随经济不停繁荣和加入WTO后市场环境改变对企业生产经营提出了更高要求企业必需综合利用多种优异制造技术在网络...
  • 共享数据仓库XMI规范

    2008-11-25 12:17:43
    XMI格式有效地标准化了任意元数据集的描述,它要求用户跨越多个工业和操作环境而使用同一种方式读取数据。   XMI是对象管理组织(OMG)提出的,它建立并扩展于三个工业标准:   1. 可扩展标记语言(XML),由...
  • 数据仓库基础

    2012-03-29 13:25:26
    第一章对数据仓库的迫切需求...................................................................................................23 本章目标:.................................................................
  • 一. 仓库进出人员规定 1.1 仓库为公司产品财产存放区,除仓管人员及保安人员外,...仓库环境维护,消防设施保养等要求 2.1 为了确保仓库所有物料完好无损及物料的品质,仓库应配备温度计,并设定室内温度标准...

    一.             仓库进出人员规定

    1.1 仓库为公司产品财产存放区,除仓管人员及保安人员外,其他因公需进入仓库人员必须进行登记;

    1.2        对於非仓管人员不准私自随意拿取物料,不准随意到仓储区域走动,无公事人员不准在仓库停留;

    二.仓库环境维护,消防设施保养等要求

    2.1        为了确保仓库所有物料完好无损及物料的品质,仓库应配备温度计,并设定室内温度标准,每天点检;

    2.2        为了保证仓储的安全与防火,仓库要有平面图及逃生图,并挂于明显之处,所有仓管人员必须熟悉;

    2.3        仓储规划要清晰,物品摆放要整齐,所有物品不准占用物流及人流通道,更不能将消防栓及消防器材堵塞;

    2.4        仓库“5S”工作要责任到人。每一个人都要有良好的“5S“意识,并切实在每天的工作中执行下去;

    2.5        定期检查仓库设施,严格做好仓库防火、防盗、防潮、防水措施;

    三.仓管人员职责

      3.1 根据生产计划做好日常收发料作业,并为生产部门及时做好物料准备及到料的及时通知;

    3.2 每日收发料作业的料卡填写,手工帐的准确维护,每日表单需及时上交帐务进行系统维护;

    3.3 仓储按照5S要求进行日常维护,不良品及时区分处理,退料的及时完成,配合IQC及采购的工作;

    3.4 定期对库存实物进行盘点,做到帐物一致,针对帐物差异及时找出原因,分析并杜绝再次发生;

    3.5       对於库存产品量与质的的完好保管,物料异常时配合品质及工程等相关部门做好相关工作;

    四.物料入库管理

        4.1  采购员填写“采购订单”采购物料,须经采购经理核准后下达,要求有具体的订单编号和交期;

    4.2  供应商送货时,需开《送货单》,同时需附上相应的“订单”,交仓库点收,仓库依交货明细之供应商名称、订单编号、料号、品名规格、数量与“送货单”“订单”对照并点收,如有异常须立即通知采购处理;

    4.3  点收后在供应商的“送货单”上签收,留两联送货单,分发采购一份;

    4.4  仓管员依供应商的“送货单”开“材料验收入库单”交IQC检验。IQC依据“来料检验规范”进行检验,检验后发出“材料检验报告”,仓管员依据IQC的检验结果办理入库;

    4.5  IQC检验不合格物料,严重不合格可以直接判退,开出“供应商通知单”通知供应商退货;同时开出一份“品质异常报告”交PMC与采购,同时仓管员依据检验结果对物料进行退货处理。退货单和不良材料放在待退区待供应商退货,退货时必须要求接收人签收;

    4.6  仓管员将供应商的送货单两联、材料验收单的厂商联和财务联以及退货单交给采购备案。并将验收单和退货单的存根联交电脑录入员办理电脑入帐手续;

    五.成品入库管理

    5.1 经QA检验合格之成品,由制造部物料员填写《成品入库单》,并由QA签字确认;

    3Gd; mso-char-indent-count: -2.78">5.2 制造部持经QA审核之产品《入库单》交仓管点收办理入库手续,再将入库单交记帐员开电脑入库单,递订单交付人员审核。仓管员每日AM 9:30交《成品库存日报表》给订单交付人员,制造部交《入库单》一联给订单交付人员,订单交付人员依据《入库单》跟踪成品库存状况;

    5.3 在成品入库过程中物料员应轻拿轻放,每箱必须封好胶纸,注明尾数箱,每箱注明规格型号、数量、生产令号、有QA PASS标签;

    5.4  仓管将入库的成品实物与成品入库单核对一致后签字确认,将成品放置指定区域,记录好PIN卡.办理电脑入帐;

    六.在制品出库管理

    6.1 正常生产物料领用由PMC发出《生产令》,交至仓库安排备料。仓管员必须严格按生产令上的品名规格、型号、数量、料号认真核对。如有不符,及时通知PMC、核对无误后方可发料;

    6.2仓库备料完毕后,通知生产物料员到仓库领料,点收。确认数量、品名规格、型号无误时,在生产令上双方签字,出货完成后录入员及时做好销帐处理;

    6.3 非正常生产物料领用,如研发、维修、办公等,先由领用部门填写“物料申请单”,交本部门主管签字确认,交总经理核准后,方可领料;

    6.4 生产不良损耗料领用,由制造部填写“物料出入库申请表”,将不良品交QA检验确认,通过物料出入库申请单到仓库领料,不良品处理依“物料管控流程”执行;

    6.5        所有物料的出库必须做到“先进先出”原则;

    七.成品出库 

    7.1 成品出货由营销部商务人员依存货情况开出《出货通知单》(必须有财务或总经理签字),通知订单交付人员安排出货,并经OQC检验合格后,通知仓管员出货。销售员需与承运人签订运输合同后,订单交付通知货运公司,仓库方可发货;

    7.2 发货时须经收货人签字确认,发货完毕,仓管员将销售和约单交电脑记帐员办理电脑帐手续;

    7.3        仓库将定期组织盘点,确保帐、卡、实物的一致性;

    八.储存与防护:

    8.1 所有材料、半成品和成品均应按仓储规划和标识要求储存;

    8.2 仓管人员应按“材料储存期限规定表”,对储存材料报检,由质量控制部IQC人员对其检测并填写检验报告交仓库,以防止材料变质。如检验判定需报废时,由仓库填写《报废申请单》经总经理核准后,方可报废。

    8.3 仓库人员应对材料、半成品和成品采取有效的防护措施,特别是对质量有重大影响的材料应采取隔离保护措施,如防潮、防静电、防氧化等,不允许直接落地,应存放于栈板上。贵重物品、化学物品应严格按指定区域摆放,并做好相应的防范措施。

    8.4  库存三个月以上的成品出货时,仓管员须通知品保重新检测,对不合格品则依《不合格品控制程序》处理。

    8.5 货仓储存坚持防火、防水、防压、定点、定位、定量、先进先出原则物料堆放时要做到“上小下大,上轻下重”容易受潮的物料严禁摆放在地上,呆废料与良品分开储存。

    8.6       仓库环境要求通风、干燥、明亮、清洁、通畅;严禁烟火,配置适量的消防器材。 

    转载于:https://www.cnblogs.com/shao-shao/articles/3380822.html

    展开全文
  • 社会在不断进步,科学技术和管理也在迅速发展,这使得每个企业得到了前所未有的发展机遇,但同时也必须面对市场竞争的严重挑战,在日趋激烈的竞争环境下,企业要求生存、发展,就必须对企业进行科学的管理。...
  • 一个复杂的示例是一个仓库,该仓库存储依赖外部依赖项的Web服务的源代码,必须在构建中进行编译,并且包括用于测试,代码统计和部署到生产基础结构的自动化。 在这两个示例中,回购在概念上都可以认为是具有定义的...
  • 用MSBuild和Jenkins搭建持续集成环境.你或其他人刚刚写完了一段代码,提交到项目的版本仓库里面。但等一下,如果新提交的代码把构建搞坏了怎么办?万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准所...
  • 仓库复制到您的本地环境: $ git clone git@github.com:hippophp/hippo.git 然后安装依赖项: $ cd hippo $ composer install 用法 将Hippo放入目录后,您可以使用以下命令运行它: $ ./bin/hippo ./src ...
  • 万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准要求的底限,你该怎么办?   最不靠谱的解决方案就是寄希望于所有人都是精英,他们根本不会犯这些错误。但如果真的出现了这些问题,我们就希望...

    用MSBuild和Jenkins搭建持续集成环境(1) 

     

    你或其他人刚刚写完了一段代码,提交到项目的版本仓库里面。但等一下,如果新提交的代码把构建搞坏了怎么办?万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准所要求的底限,你该怎么办?

     

    最不靠谱的解决方案就是寄希望于所有人都是精英,他们根本不会犯这些错误。但如果真的出现了这些问题,我们就希望发现的越早越好。最好的方式就是只要有代码提交,我们就有某种方式对它进行验证。这就是持续集成的作用。

     

    持续集成相关的工具有很多。最流行的要数一款基于Java的名叫Jenkins的工具。它提供了Web界面,用户可以在界面上配置Job,每个 Job都包含一系列的构建步骤。Jenkins可以完成开头那个场景中所提到的所有验证工作,它还能更进一步做自动化部署或者一键式部署。

     

     

    Jenkins是由Sun的前员工开发的,它的根基是Java,但也可以用在非Java的项目里,比如PHP、Ruby on Rails、.NET。在.NET项目里,你除了Jenkins之外还要熟悉另一样工具:MSBuild。

     

    Visual Studio用MSBuild构建.NET项目。MSBuild所需的仅仅是一个脚本,在脚本中指定要执行的target。项目中的.csproj和.vbproj 文件都是MSBuild脚本。

     

    在这篇文章中,我们会从头开始,一步步完成一个属于我们自己的MSBuild脚本。在它完成以后,我们只需要一个命令就可以删除之前的构建产物,构 建.NET应用,运行单元测试。后面我们还会配一个Jenkins Job,让它从代码库中更新代码,执行MSBuild脚本。最后还会配另一个Jenkins Job,让它监听第一个Job的结果,当第一步成功以后,它会把相关的构建产物复制出来,放到web服务器里启动运行。

     

    我们用一个ASP.NET MVC 3应用做例子,在VS里面创建ASP.NET MVC 3应用并选择“application”模版就行。我们还要用一个单元测试项目来跑测试。代码可以在这里下载

     

    你好,MSBuild

     

    MSBuild是在.NET 2.0中引入的针对Visual Studio的构建系统。它可以执行构建脚本,完成各种Task──最主要的是把.NET项目编译成可执行文件或者DLL。从技术角度来说,制作EXE或 者DLL的重要工作是由编译器(csc,vbc等等)完成的。MSBuild会从内部调用编译器,并完成其他必要的工作(例如拷贝引用 ──CopyLocal,执行构建前后的准备及清理工作等)

     

    这些工作都是MSBuild执行脚本中的Task完成的。MSBuild脚本就是XML文件,根元素是Project,使用MSBuild自己的命 名空间。MSBuild文件都要有Target。Target由Task组成,MSBuild运行这些Task,完成一个完整的目标。Target中可以 不包含Task,但是所有的Target都要有名字。

     

    下面来一起创建一个“Hello World”的MSBuild脚本,先保证配置正确。我建议用VS来写,因为它可以提供IntelliSense支持,不过用文本编辑器也无所谓,因为只 是写个XML文件,IntelliSense的用处也不是很大。先创建一个XML文件,命名为“basics.msbuild”,这个扩展名只是个约定而 已,好让我们容易认出这是个MSBuild脚本,你倒不用非写这样的扩展名。给文件添加一个Project元素作为根元素,把 http://schemas.microsoft.com/developer/msbuild/2003设置成命名空间,如下所示

     

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    </Project>
    

     

    下一步,给Project元素添加一个Target元素,起名叫“EchoGreeting”

     

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
        <Target Name="EchoGreeting" />
    </Project>
    

     

    这就行了。我们已经有了一个可以运行的MSBuild脚本。它虽然还啥事都没干,但我们可以用它来验证当前环境是不是可以运行MSBuild脚本。 在运行脚本的时候,我们要用到.NET框架安装路径下的MSBuild可执行文件。打开命令行,执行“MSBuild /nologo /version”命令,看看.NET框架安装路径是不是放到了PATH环境变量里面。如果一切正确,你应该能看到屏幕上打印出MSBuild的当前版 本。倘若没有的话,或者把.NET框架安装路径放到PATH里面去,或者直接用Visual Studio Command Prompt,它已经把该配的都配好了。

     

    进入存放刚才那个脚本的目录后,以文件名当作参数调用MSBuild,就可以执行脚本了。在我的机器上可以看到下面的执行结果:

     

    C:\>msbuild basics.msbuild
    Microsoft (R) Build Engine Version 4.0.30319.1
    [Microsoft .NET Framework, Version 4.0.30319.269]
    Copyright (C) Microsoft Corporation 2007. All rights reserved.
    
    Build started 8/2/2012 5:59:45 AM.
    
    Build succeeded.
     0 Warning(s)
     0 Error(s)
    Time Elapsed 00:00:00.03
    

     

    执行完脚本以后,MSBuild会首先显示一个启动界面和版权信息(用 /nologo 开关可以隐藏掉它们)。接下来会显示一个启动时间,然后便是真正的构建过程。因为咱们的脚本啥都没干,所以构建就直接成功了。总计用时也会显示在界面上。 下面咱们来给EchoGreeting Target添加一个Task,让脚本真的干点事。

     

    <Target Name="EchoGreeting">
        lt;Exec Command="echo Hello from MSBuild" />
    </Target>
    

     

    现在EchoGreeting Target有了一个Exec Task,它会执行Command属性中定义的任何命令。再运行一次脚本,你应该能看到更多信息了。在大多数时候,MSBuild的输出信息都很长,你可 以用 /verbosity 开关来只显示必要信息。不过无论怎样,MSBuild都会把我们的文字显示到屏幕上。下面再添加一个Target。

     

    <Target Name="EchoDate">
     <Exec Command="echo %25date%25" />
    </Target>
    

     

    这个Target会输出当前日期。它的命令要做的事情就是“echo %25date%25”,但是“%”字符在MSBuild中有特殊含义,所以这个命令需要被转义。当遇到转义字符的时候,“%”后面的十进制字符会被转成 对应的ASCII码。MSBuild只会执行Project元素中的第一个Target。要执行其他Target的时候,需要把/target开关(可简 写为 /t)加上Target名称传给MSBuild。你也可以指定MSBuild执行多个Target,只要用分号分割Target名字就可以。

     

    C:\>msbuild basics.msbuild /nologo /verbosity:minimal /t:EchoGreeting;EchoDate
     Hello from MSBuild
     Thu 08/02/2012
    

     

    更实用的构建脚本

     

    演示就先到这里。下面来用MSBuild来构建一个真实项目。首先把示例代码下载下来,或是自己创建一个ASP.NET应用。给它添加一个MSBuild脚本,以solution或project名字给脚本命名,扩展名用“.msbuild”。照先前一样指定MSBuild命名空间。

     

    开始写脚本之前,先把脚本要干的事情列出来:

     

    1. 创建BuildArtifacts目录
    2. 构建solution,把构建产物(DLL,EXE,静态内容等等)放到BuildArtifacts目录下。
    3. 运行单元测试。

     

    因为示例应用叫做HelloCI,于是这个脚本也就命名为HelloCI.msbuild。先添加命名空间,然后就可以添加第一个Target了,我管它叫做Init。

     

    <Target Name="Init">
     <MakeDir Directories="BuildArtifacts" />
    </Target>
    

     

    这个Target会调用MakeDir Task创建一个新的目录,名叫BuildArtifacts,跟脚本在同一目录下。运行脚本,你会发现该目录被成功创建。如果再次运行,MSBuild就会跳过这个Task,因为同名目录已经存在了。

     

    接下来写一个Clean Target,它负责删除BuildArtifacts目录和里面的文件。

     

    <Target Name="Clean">
     <RemoveDir Directories="BuildArtifacts" />
    </Target>
    

     

    理解了Init之后,这段脚本就应该很好懂了。试着执行一下,BuildArtifacts目录应该就被删掉了。下面再来把代码中的重复干掉。在 Init和Clean两个Target里面,我们都把BuildArtifacts的目录名硬编码到代码里面了,如果未来要修改这个名字的话,就得同时改 两个地方。这里可以利用Item或Property避免这种问题。

     

    Item和Property只有些许差别。Property由简单的键值对构成,在脚本执行的时候还可以用 /property 赋值。Item更强大一些,它可以用来存储更复杂的数据。我们这里不用任何复杂数据,但需要用Items获取额外的元信息,例如文件全路径。

     

    接下来修改一下脚本,用一个Item存放路径名,然后修改Init和Clean,让它们引用这个Item。

     

    <ItemGroup>
     <BuildArtifactsDir Include="BuildArtifacts\" />
    </ItemGroup>
    
    <Target Name="Init">
     <MakeDir Directories="@(BuildArtifactsDir)" />
    </Target>
    
    <Target Name="Clean">
     <RemoveDir Directories="@(BuildArtifactsDir)" />
    </Target>
    

     

    Item是在ItemGroup里面定义的。在一个Project中可以有多个ItemGroup元素,用来把有关系的Item分组。这个功能在 Item较多的时候特别有用。我们在ItemGroup里定义了BuildArtifactsDir元素,并用Include属性指定 BuildArtifacts目录。记得BuildArtifacts目录后面要有个斜杠。最后,我们用了@(ItemName)语法在Target里面 引用这个目录。现在如果要修改目录名的话,只需要改BuildArtifactsDir的Include属性就好了。

     

    接下来还有个问题要处理。在BuildArtifacts目录已经存在的情况下,Init是什么事都不干的。也是就说,在调用Init的时候磁盘上 的已有文件还会被保留下来。这一点着实不妥,如果能每次调用Init的时候,都把目录和目录里面的所有文件都一起删掉再重新创建,就能保证后续环节都在干 净的环境下执行了。我们固然可以在每次调用Init的时候先手工调一下Clean,但给Init Target加一个DependsOnTargets属性会更简单,这个属性会告诉MSBuild,每次执行Init的时候都先执行Clean。

     

    <Target Name="Init" DependsOnTargets="Clean">
     <MakeDir Directories="@(BuildArtifactsDir)" />
    </Target>
    

     

    现在MSBuild会帮我们在调Init之前先调Clean了。跟DependsOnTargets这个属性所暗示的一样,一个Target可以依赖于多个Target,之间用分号分割就行。

     

    接下来我们要编译应用程序,把编译后的结果放到BuildArtifacts目录下。先写一个Compile Target,让它依赖于Init。这个Target会调用另一个MSBuild实例来编译应用。我们把BuildArtifacts目录传进去,作为编 译结果的输出目录。

     

    <ItemGroup>
     <BuildArtifactsDir Include="BuildArtifacts\" />
     <SolutionFile Include="HelloCI.sln" />
    </ItemGroup>
    
    <PropertyGroup>
     <Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
     <BuildPlatform Condition=" '$(BuildPlatform)' == '' ">Any CPU</BuildPlatform>
    </PropertyGroup>
    
    <Target Name="Compile" DependsOnTargets="Init">
     <MSBuild Projects="@(SolutionFile)" Targets="Rebuild"
              Properties="OutDir=%(BuildArtifactsDir.FullPath);Configuration=$(Configuration);Platform=$(BuildPlatform)" />
    </Target>
    

     

    上面的脚本做了几件事情。首先,ItemGroup添加了另一个Item,叫做SolutionFile,它指向solution文件。在构建脚本中用Item或Property代替硬编码,这算的是一个优秀实践吧。

     

    其次,我们创建了一个PropertyGroup,里面包含两个Property:Configuration和BuildPlatform。它们 的值分别是“Release”和“Any CPU”。当然,Property也可以在运行时通过/property(简写为/p)赋值。我们还用了Condition属性,它在这里的含义是,只有 当这两个属性没有值的情况下,才用我们定义的数据给它们赋值。这段代码实际上就是给它们一个默认值。

     

    接下来就是Compile Target了,它依赖于Init,里面内嵌了一个MSBuild Task。它在运行的时候会调用另外一个MSBuild实例。在脚本中定义了这个被内嵌的MSBuild Task要操作的项目。在这里,我们既可以传入另外一个MSBuild脚本,也可以传入.csproj文件(它本身也是个MSBuild脚本)。但我们选 择了传入HelloCI应用的solution文件。Solution文件不是MSBuild脚本,但是MSBuild可以解析它。脚本中还指定了内嵌的 MSBuild Task要执行的Target名称:“Rebuild”,这个Target已经被导入到solution的.csproj文件中了。最后,我们给内嵌的 Task传入了三个Property。

     

    OutDir

     

              编译结果的输出目录

     

    Configuration

     

              构建(调试、发布等)时要使用的配置

     

    Platform

     

              编译所用的平台(x86、x64等)

     

    给上面这三个Property赋值用的就是先前定义的Item和Property。OutDir Property用的是BuildArtifacts目录的全路径。这里用了%(Item.MetaData) 语法。这个语法应该看起来很眼熟吧?就跟访问C#对象属性的语法一样。MSBuild创建出来的任何Item,都提供了某些元数据以供访问,例如 FullPath和ModifiedTime。但这些元数据有时候也没啥大用,因为Item不一定是文件。

     

    Configuration和Platform用到了先前定义好的Property,语法格式是$(PropertyName)。在这里可以看到系统保留的一些属性名,用户不能更改。定义Property的时候请不要用它们。

     

    这里还有些东西值得提一下。用了Property以后,我们可以在不更改构建脚本的情况下使用不同的Configuration或者 BuildPlatform,只要在运行的时候用 /property 传值进去就行。所以“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Debug”这个命令会用Debug配置构建项目,而“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Test;BuildPlatform:x86”会在x86平台下使用Test配置。

     

    现在运行Compile,就可以编译solution下的两个项目,把编译结果放到BuildArtifacts目录下。在完成构建脚本之前,只剩下最后一个Target了:

     

    <ItemGroup>
     <BuildArtifacts Include="BuildArtifacts\" />
     <SolutionFile Include="HelloCI.sln" />
     <NUnitConsole Include="C:\Program Files (x86)\NUnit 2.6\bin\nunit-console.exe" />
     <UnitTestsDLL Include="BuildArtifacts\HelloCI.Web.UnitTests.dll" />
     <TestResultsPath Include="BuildArtifacts\TestResults.xml" />
    </ItemGroup>
    
    <Target Name="RunUnitTests" DependsOnTargets="Compile">
     <Exec Command='"@(NUnitConsole)" @(UnitTestsDLL) /xml=@(TestResultsPath)' />
    </Target>
    

     

    ItemGroup里现在又多了三个Item:NUnitConsole指向NUnit控制台运行器(console runner);UnitTestDLL指向单元测试项目生成的DLL文件;TestResultsPath是要传给NUnit的,这样测试结果就会放到 BuildArtifacts目录下。

     

    RunUnitTests Target用到了Exec Task。如果有一个测试运行失败,NUnit控制台运行器会返回一个非0的结果。这个返回值会告诉MSBuild有个地方出错了,于是整个构建的状态就是失败。

     

    现在这个脚本比较完善了,用一个命令就可以删除旧的构建产物、编译、运行单元测试:

     

    C:\HelloCI\> msbuild HelloCI.msbuild /t:RunUnitTests
    

     

    我们还可以给脚本设一个默认Target,就省得某次都要指定了。在Project元素上加一个DefaultTargets属性,让RunUnitTests成为默认Target。

     

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
                    DefaultTargets="RunUnitTests">
    

     

    你还可以创建自己的Task。这里有个例子,AsyncExec,它允许人们以异步的方式执行命令。比如有个Target用来启动Web服务器,要是用Exec命令的话,整个构建都会停住,直到服务器关闭。用AsyncExec这个命令可以让构建继续执行,不用等待命令执行结束。

     

    本文的完整脚本可以在这里下载

     

    在接下来的文章中,我会讲述如何配置Jenkins。我们不再需要手动运行命令来构建整个项目,Jenkins会检测代码库,一旦有更新就会自动触发构建。

     

     

    查看英文原文Continuous Integration with MSBuild and Jenkins – Part 1

    展开全文
  • 万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准要求的底限,你该怎么办? 最不靠谱的解决方案就是寄希望于所有人都是精英,他们根本不会犯这些错误。但如果真的出现了这些问题,我们就希望发现的...

    你或其他人刚刚写完了一段代码,提交到项目的版本仓库里面。但等一下,如果新提交的代码把构建搞坏了怎么办?万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准所要求的底限,你该怎么办?

    最不靠谱的解决方案就是寄希望于所有人都是精英,他们根本不会犯这些错误。但如果真的出现了这些问题,我们就希望发现的越早越好。最好的方式就是只要有代码提交,我们就有某种方式对它进行验证。这就是持续集成的作用。

    持续集成相关的工具有很多。最流行的要数一款基于Java的名叫Jenkins的工具。它提供了Web界面,用户可以在界面上配置Job,每个Job都包含一系列的构建步骤。Jenkins可以完成开头那个场景中所提到的所有验证工作,它还能更进一步做自动化部署或者一键式部署。


    Jenkins是由Sun的前员工开发的,它的根基是Java,但也可以用在非Java的项目里,比如PHP、Ruby on Rails、.NET。在.NET项目里,你除了Jenkins之外还要熟悉另一样工具:MSBuild。

    Visual Studio用MSBuild构建.NET项目。MSBuild所需的仅仅是一个脚本,在脚本中指定要执行的target。项目中的.csproj和.vbproj 文件都是MSBuild脚本。

    在这篇文章中,我们会从头开始,一步步完成一个属于我们自己的MSBuild脚本。在它完成以后,我们只需要一个命令就可以删除之前的构建产物,构建.NET应用,运行单元测试。后面我们还会配一个Jenkins Job,让它从代码库中更新代码,执行MSBuild脚本。最后还会配另一个Jenkins Job,让它监听第一个Job的结果,当第一步成功以后,它会把相关的构建产物复制出来,放到web服务器里启动运行。

    我们用一个ASP.NET MVC 3应用做例子,在VS里面创建ASP.NET MVC 3应用并选择“application”模版就行。我们还要用一个单元测试项目来跑测试。代码可以在这里下载

    你好,MSBuild

    MSBuild是在.NET 2.0中引入的针对Visual Studio的构建系统。它可以执行构建脚本,完成各种Task──最主要的是把.NET项目编译成可执行文件或者DLL。从技术角度来说,制作EXE或者DLL的重要工作是由编译器(csc,vbc等等)完成的。MSBuild会从内部调用编译器,并完成其他必要的工作(例如拷贝引用──CopyLocal,执行构建前后的准备及清理工作等)

    这些工作都是MSBuild执行脚本中的Task完成的。MSBuild脚本就是XML文件,根元素是Project,使用MSBuild自己的命名空间。MSBuild文件都要有Target。Target由Task组成,MSBuild运行这些Task,完成一个完整的目标。Target中可以不包含Task,但是所有的Target都要有名字。

    下面来一起创建一个“Hello World”的MSBuild脚本,先保证配置正确。我建议用VS来写,因为它可以提供IntelliSense支持,不过用文本编辑器也无所谓,因为只是写个XML文件,IntelliSense的用处也不是很大。先创建一个XML文件,命名为“basics.msbuild”,这个扩展名只是个约定而已,好让我们容易认出这是个MSBuild脚本,你倒不用非写这样的扩展名。给文件添加一个Project元素作为根元素,把 http://schemas.microsoft.com/developer/msbuild/2003设置成命名空间,如下所示

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    </Project>
    

    下一步,给Project元素添加一个Target元素,起名叫“EchoGreeting”

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
        <Target Name="EchoGreeting" />
    </Project>
    

    这就行了。我们已经有了一个可以运行的MSBuild脚本。它虽然还啥事都没干,但我们可以用它来验证当前环境是不是可以运行MSBuild脚本。在运行脚本的时候,我们要用到.NET框架安装路径下的MSBuild可执行文件。打开命令行,执行“MSBuild /nologo /version”命令,看看.NET框架安装路径是不是放到了PATH环境变量里面。如果一切正确,你应该能看到屏幕上打印出MSBuild的当前版本。倘若没有的话,或者把.NET框架安装路径放到PATH里面去,或者直接用Visual Studio Command Prompt,它已经把该配的都配好了。

    进入存放刚才那个脚本的目录后,以文件名当作参数调用MSBuild,就可以执行脚本了。在我的机器上可以看到下面的执行结果:

    C:\>msbuild basics.msbuild
    Microsoft (R) Build Engine Version 4.0.30319.1
    [Microsoft .NET Framework, Version 4.0.30319.269]
    Copyright (C) Microsoft Corporation 2007. All rights reserved.
    
    Build started 8/2/2012 5:59:45 AM.
    
    Build succeeded.
     0 Warning(s)
     0 Error(s)
    Time Elapsed 00:00:00.03
    

    执行完脚本以后,MSBuild会首先显示一个启动界面和版权信息(用 /nologo 开关可以隐藏掉它们)。接下来会显示一个启动时间,然后便是真正的构建过程。因为咱们的脚本啥都没干,所以构建就直接成功了。总计用时也会显示在界面上。下面咱们来给EchoGreeting Target添加一个Task,让脚本真的干点事。

    <Target Name="EchoGreeting">
        lt;Exec Command="echo Hello from MSBuild" />
    </Target>
    

    现在EchoGreeting Target有了一个Exec Task,它会执行Command属性中定义的任何命令。再运行一次脚本,你应该能看到更多信息了。在大多数时候,MSBuild的输出信息都很长,你可以用 /verbosity 开关来只显示必要信息。不过无论怎样,MSBuild都会把我们的文字显示到屏幕上。下面再添加一个Target。

    <Target Name="EchoDate">
     <Exec Command="echo %25date%25" />
    </Target>
    

    这个Target会输出当前日期。它的命令要做的事情就是“echo %25date%25”,但是“%”字符在MSBuild中有特殊含义,所以这个命令需要被转义。当遇到转义字符的时候,“%”后面的十进制字符会被转成对应的ASCII码。MSBuild只会执行Project元素中的第一个Target。要执行其他Target的时候,需要把/target开关(可简写为 /t)加上Target名称传给MSBuild。你也可以指定MSBuild执行多个Target,只要用分号分割Target名字就可以。

    C:\>msbuild basics.msbuild /nologo /verbosity:minimal /t:EchoGreeting;EchoDate
     Hello from MSBuild
     Thu 08/02/2012
    

    更实用的构建脚本

    演示就先到这里。下面来用MSBuild来构建一个真实项目。首先把示例代码下载下来,或是自己创建一个ASP.NET应用。给它添加一个MSBuild脚本,以solution或project名字给脚本命名,扩展名用“.msbuild”。照先前一样指定MSBuild命名空间。

    开始写脚本之前,先把脚本要干的事情列出来:

    1. 创建BuildArtifacts目录
    2. 构建solution,把构建产物(DLL,EXE,静态内容等等)放到BuildArtifacts目录下。
    3. 运行单元测试。

    因为示例应用叫做HelloCI,于是这个脚本也就命名为HelloCI.msbuild。先添加命名空间,然后就可以添加第一个Target了,我管它叫做Init。

    <Target Name="Init">
     <MakeDir Directories="BuildArtifacts" />
    </Target>
    

    这个Target会调用MakeDir Task创建一个新的目录,名叫BuildArtifacts,跟脚本在同一目录下。运行脚本,你会发现该目录被成功创建。如果再次运行,MSBuild就会跳过这个Task,因为同名目录已经存在了。

    接下来写一个Clean Target,它负责删除BuildArtifacts目录和里面的文件。

    <Target Name="Clean">
     <RemoveDir Directories="BuildArtifacts" />
    </Target>
    

    理解了Init之后,这段脚本就应该很好懂了。试着执行一下,BuildArtifacts目录应该就被删掉了。下面再来把代码中的重复干掉。在Init和Clean两个Target里面,我们都把BuildArtifacts的目录名硬编码到代码里面了,如果未来要修改这个名字的话,就得同时改两个地方。这里可以利用Item或Property避免这种问题。

    Item和Property只有些许差别。Property由简单的键值对构成,在脚本执行的时候还可以用 /property 赋值。Item更强大一些,它可以用来存储更复杂的数据。我们这里不用任何复杂数据,但需要用Items获取额外的元信息,例如文件全路径。

    接下来修改一下脚本,用一个Item存放路径名,然后修改Init和Clean,让它们引用这个Item。

    <ItemGroup>
     <BuildArtifactsDir Include="BuildArtifacts\" />
    </ItemGroup>
    
    <Target Name="Init">
     <MakeDir Directories="@(BuildArtifactsDir)" />
    </Target>
    
    <Target Name="Clean">
     <RemoveDir Directories="@(BuildArtifactsDir)" />
    </Target>
    

    Item是在ItemGroup里面定义的。在一个Project中可以有多个ItemGroup元素,用来把有关系的Item分组。这个功能在Item较多的时候特别有用。我们在ItemGroup里定义了BuildArtifactsDir元素,并用Include属性指定BuildArtifacts目录。记得BuildArtifacts目录后面要有个斜杠。最后,我们用了@(ItemName)语法在Target里面引用这个目录。现在如果要修改目录名的话,只需要改BuildArtifactsDir的Include属性就好了。

    接下来还有个问题要处理。在BuildArtifacts目录已经存在的情况下,Init是什么事都不干的。也是就说,在调用Init的时候磁盘上的已有文件还会被保留下来。这一点着实不妥,如果能每次调用Init的时候,都把目录和目录里面的所有文件都一起删掉再重新创建,就能保证后续环节都在干净的环境下执行了。我们固然可以在每次调用Init的时候先手工调一下Clean,但给Init Target加一个DependsOnTargets属性会更简单,这个属性会告诉MSBuild,每次执行Init的时候都先执行Clean。

    <Target Name="Init" DependsOnTargets="Clean">
     <MakeDir Directories="@(BuildArtifactsDir)" />
    </Target>
    

    现在MSBuild会帮我们在调Init之前先调Clean了。跟DependsOnTargets这个属性所暗示的一样,一个Target可以依赖于多个Target,之间用分号分割就行。

    接下来我们要编译应用程序,把编译后的结果放到BuildArtifacts目录下。先写一个Compile Target,让它依赖于Init。这个Target会调用另一个MSBuild实例来编译应用。我们把BuildArtifacts目录传进去,作为编译结果的输出目录。

    <ItemGroup>
     <BuildArtifactsDir Include="BuildArtifacts\" />
     <SolutionFile Include="HelloCI.sln" />
    </ItemGroup>
    
    <PropertyGroup>
     <Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
     <BuildPlatform Condition=" '$(BuildPlatform)' == '' ">Any CPU</BuildPlatform>
    </PropertyGroup>
    
    <Target Name="Compile" DependsOnTargets="Init">
     <MSBuild Projects="@(SolutionFile)" Targets="Rebuild"
              Properties="OutDir=%(BuildArtifactsDir.FullPath);Configuration=$(Configuration);Platform=$(BuildPlatform)" />
    </Target>
    

    上面的脚本做了几件事情。首先,ItemGroup添加了另一个Item,叫做SolutionFile,它指向solution文件。在构建脚本中用Item或Property代替硬编码,这算的是一个优秀实践吧。

    其次,我们创建了一个PropertyGroup,里面包含两个Property:Configuration和BuildPlatform。它们的值分别是“Release”和“Any CPU”。当然,Property也可以在运行时通过/property(简写为/p)赋值。我们还用了Condition属性,它在这里的含义是,只有当这两个属性没有值的情况下,才用我们定义的数据给它们赋值。这段代码实际上就是给它们一个默认值。

    接下来就是Compile Target了,它依赖于Init,里面内嵌了一个MSBuild Task。它在运行的时候会调用另外一个MSBuild实例。在脚本中定义了这个被内嵌的MSBuild Task要操作的项目。在这里,我们既可以传入另外一个MSBuild脚本,也可以传入.csproj文件(它本身也是个MSBuild脚本)。但我们选择了传入HelloCI应用的solution文件。Solution文件不是MSBuild脚本,但是MSBuild可以解析它。脚本中还指定了内嵌的MSBuild Task要执行的Target名称:“Rebuild”,这个Target已经被导入到solution的.csproj文件中了。最后,我们给内嵌的Task传入了三个Property。

    OutDir

              编译结果的输出目录

    Configuration

              构建(调试、发布等)时要使用的配置

    Platform

              编译所用的平台(x86、x64等)

    给上面这三个Property赋值用的就是先前定义的Item和Property。OutDir Property用的是BuildArtifacts目录的全路径。这里用了%(Item.MetaData) 语法。这个语法应该看起来很眼熟吧?就跟访问C#对象属性的语法一样。MSBuild创建出来的任何Item,都提供了某些元数据以供访问,例如FullPath和ModifiedTime。但这些元数据有时候也没啥大用,因为Item不一定是文件。

    Configuration和Platform用到了先前定义好的Property,语法格式是$(PropertyName)。在这里可以看到系统保留的一些属性名,用户不能更改。定义Property的时候请不要用它们。

    这里还有些东西值得提一下。用了Property以后,我们可以在不更改构建脚本的情况下使用不同的Configuration或者BuildPlatform,只要在运行的时候用 /property 传值进去就行。所以“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Debug”这个命令会用Debug配置构建项目,而“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Test;BuildPlatform:x86”会在x86平台下使用Test配置。

    现在运行Compile,就可以编译solution下的两个项目,把编译结果放到BuildArtifacts目录下。在完成构建脚本之前,只剩下最后一个Target了:

    <ItemGroup>
     <BuildArtifacts Include="BuildArtifacts\" />
     <SolutionFile Include="HelloCI.sln" />
     <NUnitConsole Include="C:\Program Files (x86)\NUnit 2.6\bin\nunit-console.exe" />
     <UnitTestsDLL Include="BuildArtifacts\HelloCI.Web.UnitTests.dll" />
     <TestResultsPath Include="BuildArtifacts\TestResults.xml" />
    </ItemGroup>
    
    <Target Name="RunUnitTests" DependsOnTargets="Compile">
     <Exec Command='"@(NUnitConsole)" @(UnitTestsDLL) /xml=@(TestResultsPath)' />
    </Target>
    

    ItemGroup里现在又多了三个Item:NUnitConsole指向NUnit控制台运行器(console runner);UnitTestDLL指向单元测试项目生成的DLL文件;TestResultsPath是要传给NUnit的,这样测试结果就会放到BuildArtifacts目录下。

    RunUnitTests Target用到了Exec Task。如果有一个测试运行失败,NUnit控制台运行器会返回一个非0的结果。这个返回值会告诉MSBuild有个地方出错了,于是整个构建的状态就是失败。

    现在这个脚本比较完善了,用一个命令就可以删除旧的构建产物、编译、运行单元测试:

    C:\HelloCI\> msbuild HelloCI.msbuild /t:RunUnitTests
    

    我们还可以给脚本设一个默认Target,就省得某次都要指定了。在Project元素上加一个DefaultTargets属性,让RunUnitTests成为默认Target。

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
                    DefaultTargets="RunUnitTests">
    

    你还可以创建自己的Task。这里有个例子,AsyncExec,它允许人们以异步的方式执行命令。比如有个Target用来启动Web服务器,要是用Exec命令的话,整个构建都会停住,直到服务器关闭。用AsyncExec这个命令可以让构建继续执行,不用等待命令执行结束。

    本文的完整脚本可以在这里下载

    在接下来的文章中,我会讲述如何配置Jenkins。我们不再需要手动运行命令来构建整个项目,Jenkins会检测代码库,一旦有更新就会自动触发构建。


    展开全文
  • 万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准要求的底限,你该怎么办? 最不靠谱的解决方案就是寄希望于所有人都是精英,他们根本不会犯这些错误。但如果真的出现了这些问题,我们就希望发现的...

    你或其他人刚刚写完了一段代码,提交到项目的版本仓库里面。但等一下,如果新提交的代码把构建搞坏了怎么办?万一出现编译错误,或者有的测试失败了,或者代码不符合质量标准所要求的底限,你该怎么办?

    最不靠谱的解决方案就是寄希望于所有人都是精英,他们根本不会犯这些错误。但如果真的出现了这些问题,我们就希望发现的越早越好。最好的方式就是只要有代码提交,我们就有某种方式对它进行验证。这就是持续集成的作用。

    持续集成相关的工具有很多。最流行的要数一款基于Java的名叫Jenkins的工具。它提供了Web界面,用户可以在界面上配置Job,每个Job都包含一系列的构建步骤。Jenkins可以完成开头那个场景中所提到的所有验证工作,它还能更进一步做自动化部署或者一键式部署。

    Jenkins是由Sun的前员工开发的,它的根基是Java,但也可以用在非Java的项目里,比如PHP、Ruby on Rails、.NET。在.NET项目里,你除了Jenkins之外还要熟悉另一样工具:MSBuild。

    Visual Studio用MSBuild构建.NET项目。MSBuild所需的仅仅是一个脚本,在脚本中指定要执行的target。项目中的.csproj和.vbproj 文件都是MSBuild脚本。

    在这篇文章中,我们会从头开始,一步步完成一个属于我们自己的MSBuild脚本。在它完成以后,我们只需要一个命令就可以删除之前的构建产物,构建.NET应用,运行单元测试。后面我们还会配一个Jenkins Job,让它从代码库中更新代码,执行MSBuild脚本。最后还会配另一个Jenkins Job,让它监听第一个Job的结果,当第一步成功以后,它会把相关的构建产物复制出来,放到web服务器里启动运行。

    我们用一个ASP.NET MVC 3应用做例子,在VS里面创建ASP.NET MVC 3应用并选择“application”模版就行。我们还要用一个单元测试项目来跑测试。代码可以在这里下载

    你好,MSBuild

    MSBuild是在.NET 2.0中引入的针对Visual Studio的构建系统。它可以执行构建脚本,完成各种Task──最主要的是把.NET项目编译成可执行文件或者DLL。从技术角度来说,制作EXE或者DLL的重要工作是由编译器(csc,vbc等等)完成的。MSBuild会从内部调用编译器,并完成其他必要的工作(例如拷贝引用──CopyLocal,执行构建前后的准备及清理工作等)

    这些工作都是MSBuild执行脚本中的Task完成的。MSBuild脚本就是XML文件,根元素是Project,使用MSBuild自己的命名空间。MSBuild文件都要有Target。Target由Task组成,MSBuild运行这些Task,完成一个完整的目标。Target中可以不包含Task,但是所有的Target都要有名字。

    下面来一起创建一个“Hello World”的MSBuild脚本,先保证配置正确。我建议用VS来写,因为它可以提供IntelliSense支持,不过用文本编辑器也无所谓,因为只是写个XML文件,IntelliSense的用处也不是很大。先创建一个XML文件,命名为“basics.msbuild”,这个扩展名只是个约定而已,好让我们容易认出这是个MSBuild脚本,你倒不用非写这样的扩展名。给文件添加一个Project元素作为根元素,把 http://schemas.microsoft.com/developer/msbuild/2003设置成命名空间,如下所示

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    </Project>
    

    下一步,给Project元素添加一个Target元素,起名叫“EchoGreeting”

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
        <Target Name="EchoGreeting" />
    </Project>
    

    这就行了。我们已经有了一个可以运行的MSBuild脚本。它虽然还啥事都没干,但我们可以用它来验证当前环境是不是可以运行MSBuild脚本。在运行脚本的时候,我们要用到.NET框架安装路径下的MSBuild可执行文件。打开命令行,执行“MSBuild /nologo /version”命令,看看.NET框架安装路径是不是放到了PATH环境变量里面。如果一切正确,你应该能看到屏幕上打印出MSBuild的当前版本。倘若没有的话,或者把.NET框架安装路径放到PATH里面去,或者直接用Visual Studio Command Prompt,它已经把该配的都配好了。

    进入存放刚才那个脚本的目录后,以文件名当作参数调用MSBuild,就可以执行脚本了。在我的机器上可以看到下面的执行结果:

    C:\>msbuild basics.msbuild
    Microsoft (R) Build Engine Version 4.0.30319.1
    [Microsoft .NET Framework, Version 4.0.30319.269]
    Copyright (C) Microsoft Corporation 2007. All rights reserved.
    
    Build started 8/2/2012 5:59:45 AM.
    
    Build succeeded.
     0 Warning(s)
     0 Error(s)
    Time Elapsed 00:00:00.03
    

    执行完脚本以后,MSBuild会首先显示一个启动界面和版权信息(用 /nologo 开关可以隐藏掉它们)。接下来会显示一个启动时间,然后便是真正的构建过程。因为咱们的脚本啥都没干,所以构建就直接成功了。总计用时也会显示在界面上。下面咱们来给EchoGreeting Target添加一个Task,让脚本真的干点事。

    <Target Name="EchoGreeting">
        lt;Exec Command="echo Hello from MSBuild" />
    </Target>
    

    现在EchoGreeting Target有了一个Exec Task,它会执行Command属性中定义的任何命令。再运行一次脚本,你应该能看到更多信息了。在大多数时候,MSBuild的输出信息都很长,你可以用 /verbosity 开关来只显示必要信息。不过无论怎样,MSBuild都会把我们的文字显示到屏幕上。下面再添加一个Target。

    <Target Name="EchoDate">
     <Exec Command="echo %25date%25" />
    </Target>
    

    这个Target会输出当前日期。它的命令要做的事情就是“echo %25date%25”,但是“%”字符在MSBuild中有特殊含义,所以这个命令需要被转义。当遇到转义字符的时候,“%”后面的十进制字符会被转成对应的ASCII码。MSBuild只会执行Project元素中的第一个Target。要执行其他Target的时候,需要把/target开关(可简写为 /t)加上Target名称传给MSBuild。你也可以指定MSBuild执行多个Target,只要用分号分割Target名字就可以。

    C:\>msbuild basics.msbuild /nologo /verbosity:minimal /t:EchoGreeting;EchoDate
     Hello from MSBuild
     Thu 08/02/2012
    

    更实用的构建脚本

    演示就先到这里。下面来用MSBuild来构建一个真实项目。首先把示例代码下载下来,或是自己创建一个ASP.NET应用。给它添加一个MSBuild脚本,以solution或project名字给脚本命名,扩展名用“.msbuild”。照先前一样指定MSBuild命名空间。

    开始写脚本之前,先把脚本要干的事情列出来:

    1. 创建BuildArtifacts目录
    2. 构建solution,把构建产物(DLL,EXE,静态内容等等)放到BuildArtifacts目录下。
    3. 运行单元测试。

    因为示例应用叫做HelloCI,于是这个脚本也就命名为HelloCI.msbuild。先添加命名空间,然后就可以添加第一个Target了,我管它叫做Init。

    <Target Name="Init">
     <MakeDir Directories="BuildArtifacts" />
    </Target>
    

    这个Target会调用MakeDir Task创建一个新的目录,名叫BuildArtifacts,跟脚本在同一目录下。运行脚本,你会发现该目录被成功创建。如果再次运行,MSBuild就会跳过这个Task,因为同名目录已经存在了。

    接下来写一个Clean Target,它负责删除BuildArtifacts目录和里面的文件。

    <Target Name="Clean">
     <RemoveDir Directories="BuildArtifacts" />
    </Target>
    

    理解了Init之后,这段脚本就应该很好懂了。试着执行一下,BuildArtifacts目录应该就被删掉了。下面再来把代码中的重复干掉。在Init和Clean两个Target里面,我们都把BuildArtifacts的目录名硬编码到代码里面了,如果未来要修改这个名字的话,就得同时改两个地方。这里可以利用Item或Property避免这种问题。

    Item和Property只有些许差别。Property由简单的键值对构成,在脚本执行的时候还可以用 /property 赋值。Item更强大一些,它可以用来存储更复杂的数据。我们这里不用任何复杂数据,但需要用Items获取额外的元信息,例如文件全路径。

    接下来修改一下脚本,用一个Item存放路径名,然后修改Init和Clean,让它们引用这个Item。

    <ItemGroup>
     <BuildArtifactsDir Include="BuildArtifacts\" />
    </ItemGroup>
    
    <Target Name="Init">
     <MakeDir Directories="@(BuildArtifactsDir)" />
    </Target>
    
    <Target Name="Clean">
     <RemoveDir Directories="@(BuildArtifactsDir)" />
    </Target>
    

    Item是在ItemGroup里面定义的。在一个Project中可以有多个ItemGroup元素,用来把有关系的Item分组。这个功能在Item较多的时候特别有用。我们在ItemGroup里定义了BuildArtifactsDir元素,并用Include属性指定BuildArtifacts目录。记得BuildArtifacts目录后面要有个斜杠。最后,我们用了@(ItemName)语法在Target里面引用这个目录。现在如果要修改目录名的话,只需要改BuildArtifactsDir的Include属性就好了。

    接下来还有个问题要处理。在BuildArtifacts目录已经存在的情况下,Init是什么事都不干的。也是就说,在调用Init的时候磁盘上的已有文件还会被保留下来。这一点着实不妥,如果能每次调用Init的时候,都把目录和目录里面的所有文件都一起删掉再重新创建,就能保证后续环节都在干净的环境下执行了。我们固然可以在每次调用Init的时候先手工调一下Clean,但给Init Target加一个DependsOnTargets属性会更简单,这个属性会告诉MSBuild,每次执行Init的时候都先执行Clean。

    <Target Name="Init" DependsOnTargets="Clean">
     <MakeDir Directories="@(BuildArtifactsDir)" />
    </Target>
    

    现在MSBuild会帮我们在调Init之前先调Clean了。跟DependsOnTargets这个属性所暗示的一样,一个Target可以依赖于多个Target,之间用分号分割就行。

    接下来我们要编译应用程序,把编译后的结果放到BuildArtifacts目录下。先写一个Compile Target,让它依赖于Init。这个Target会调用另一个MSBuild实例来编译应用。我们把BuildArtifacts目录传进去,作为编译结果的输出目录。

    <ItemGroup>
     <BuildArtifactsDir Include="BuildArtifacts\" />
     <SolutionFile Include="HelloCI.sln" />
    </ItemGroup>
    
    <PropertyGroup>
     <Configuration Condition=" '$(Configuration)' == '' ">Release</Configuration>
     <BuildPlatform Condition=" '$(BuildPlatform)' == '' ">Any CPU</BuildPlatform>
    </PropertyGroup>
    
    <Target Name="Compile" DependsOnTargets="Init">
     <MSBuild Projects="@(SolutionFile)" Targets="Rebuild"
              Properties="OutDir=%(BuildArtifactsDir.FullPath);Configuration=$(Configuration);Platform=$(BuildPlatform)" />
    </Target>
    

    上面的脚本做了几件事情。首先,ItemGroup添加了另一个Item,叫做SolutionFile,它指向solution文件。在构建脚本中用Item或Property代替硬编码,这算的是一个优秀实践吧。

    其次,我们创建了一个PropertyGroup,里面包含两个Property:Configuration和BuildPlatform。它们的值分别是“Release”和“Any CPU”。当然,Property也可以在运行时通过/property(简写为/p)赋值。我们还用了Condition属性,它在这里的含义是,只有当这两个属性没有值的情况下,才用我们定义的数据给它们赋值。这段代码实际上就是给它们一个默认值。

    接下来就是Compile Target了,它依赖于Init,里面内嵌了一个MSBuild Task。它在运行的时候会调用另外一个MSBuild实例。在脚本中定义了这个被内嵌的MSBuild Task要操作的项目。在这里,我们既可以传入另外一个MSBuild脚本,也可以传入.csproj文件(它本身也是个MSBuild脚本)。但我们选择了传入HelloCI应用的solution文件。Solution文件不是MSBuild脚本,但是MSBuild可以解析它。脚本中还指定了内嵌的MSBuild Task要执行的Target名称:“Rebuild”,这个Target已经被导入到solution的.csproj文件中了。最后,我们给内嵌的Task传入了三个Property。

    OutDir

              编译结果的输出目录

    Configuration

              构建(调试、发布等)时要使用的配置

    Platform

              编译所用的平台(x86、x64等)

    给上面这三个Property赋值用的就是先前定义的Item和Property。OutDir Property用的是BuildArtifacts目录的全路径。这里用了%(Item.MetaData) 语法。这个语法应该看起来很眼熟吧?就跟访问C#对象属性的语法一样。MSBuild创建出来的任何Item,都提供了某些元数据以供访问,例如FullPath和ModifiedTime。但这些元数据有时候也没啥大用,因为Item不一定是文件。

    Configuration和Platform用到了先前定义好的Property,语法格式是$(PropertyName)。在这里可以看到系统保留的一些属性名,用户不能更改。定义Property的时候请不要用它们。

    这里还有些东西值得提一下。用了Property以后,我们可以在不更改构建脚本的情况下使用不同的Configuration或者BuildPlatform,只要在运行的时候用 /property 传值进去就行。所以“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Debug”这个命令会用Debug配置构建项目,而“msbuild HelloCI.msbuild /t:Compile /p:Configuration:Test;BuildPlatform:x86”会在x86平台下使用Test配置。

    现在运行Compile,就可以编译solution下的两个项目,把编译结果放到BuildArtifacts目录下。在完成构建脚本之前,只剩下最后一个Target了:

    <ItemGroup>
     <BuildArtifacts Include="BuildArtifacts\" />
     <SolutionFile Include="HelloCI.sln" />
     <NUnitConsole Include="C:\Program Files (x86)\NUnit 2.6\bin\nunit-console.exe" />
     <UnitTestsDLL Include="BuildArtifacts\HelloCI.Web.UnitTests.dll" />
     <TestResultsPath Include="BuildArtifacts\TestResults.xml" />
    </ItemGroup>
    
    <Target Name="RunUnitTests" DependsOnTargets="Compile">
     <Exec Command='"@(NUnitConsole)" @(UnitTestsDLL) /xml=@(TestResultsPath)' />
    </Target>
    

    ItemGroup里现在又多了三个Item:NUnitConsole指向NUnit控制台运行器(console runner);UnitTestDLL指向单元测试项目生成的DLL文件;TestResultsPath是要传给NUnit的,这样测试结果就会放到BuildArtifacts目录下。

    RunUnitTests Target用到了Exec Task。如果有一个测试运行失败,NUnit控制台运行器会返回一个非0的结果。这个返回值会告诉MSBuild有个地方出错了,于是整个构建的状态就是失败。

    现在这个脚本比较完善了,用一个命令就可以删除旧的构建产物、编译、运行单元测试:

    C:\HelloCI\> msbuild HelloCI.msbuild /t:RunUnitTests
    

    我们还可以给脚本设一个默认Target,就省得某次都要指定了。在Project元素上加一个DefaultTargets属性,让RunUnitTests成为默认Target。

    <Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
                    DefaultTargets="RunUnitTests">
    

    你还可以创建自己的Task。这里有个例子,AsyncExec,它允许人们以异步的方式执行命令。比如有个Target用来启动Web服务器,要是用Exec命令的话,整个构建都会停住,直到服务器关闭。用AsyncExec这个命令可以让构建继续执行,不用等待命令执行结束。

    本文的完整脚本可以在这里下载

    在接下来的文章中,我会讲述如何配置Jenkins。我们不再需要手动运行命令来构建整个项目,Jenkins会检测代码库,一旦有更新就会自动触发构建。

    作者简介

    Mustafa Saeed Haji Ali居住在Somaliland的Hargeisa。他是个程序员,最常用的是ASP.NET MVC。Mustafa喜欢测试,喜欢用Javascript框架,如KnockoutJS、AngularJS、SignalR。他热衷于传播最佳实践。

     
     
     

    转载于:https://www.cnblogs.com/zengxlf/p/3147275.html

    展开全文
  • Oracle 11g数据库安装与配置 1简答题 1 企业版数据库服务器包含所有的数据库组件主要针对高端的应用环境适用于安全性和性能要求较高的联机事务处理OLTP查询密集型的数据仓库要求较高的Internet应用程序标准版...
  • 答:企业版的数据库包含所有的数据库组件,主要用于对安全性、性能要求高的环境标准版的数据库提供了绝大部分的核心功能和特性,主要用于一些工作部门环境。个人版的数据库只提供了一些基本的功能和特性,主要用于...
  • oracle 11g数据库的版本与区别

    千次阅读 2013-05-04 19:39:25
    个人版: 只提供基本的数据库管理服务,适用于单用户开发部署 标准版: ...适用于对高端应用程序的数据管理,如大容量的联机事务处理(OLTP)环境、查询密集型的数据仓库要求较高的Internet应用程序等
  • 温湿度监测系统用于监控仓库内的温湿度环境参数,实现符合GSP/GMP认证要求的药厂环境。该系统能对大面积的温度/湿度等环境参数进行监测,并将数据传输到PC机上进行数据存储与分析,并输出打印曲线。在设备异常情况下...
  • 在同一个服务仓库中的服务都符合同样的合同设计标准 服务松耦合 服务合同施加了消费者低耦合的要求,而它们自己也与周围的环境脱钩 服务抽象 服务合同只包含基本信息, 以及仅能发布在服务合同中的与服务有关的信息 ...
  • 药品监督部门颁布的新版《药品经营质量管理规范》中明确要求,在储存药品的仓库中和运输冷藏、冷冻药品的设备中配备温湿度自动监测系统,对药品储存过程的温湿度状况进行实时自动监测和记录。 二、方案介绍 药品库房...
  • (三)物流标准化的要求 33 二、物流标准化的重要性 34 第3章 仓储作业管理 37 第1节 入库管理 38 一、入库作业流程 38 (一)影响入库作业的因素 38 (二)入库作业原则 39 (三)入库作业程序 39 二、入库作业常见的问题 ...
  • xmi 转自百度百科

    千次阅读 2013-07-19 10:02:42
    xmi XMI(XML-based Metadata Interchange) 使用扩展标记语言(XML),为程序员和其它用户提供元...XMI格式有效地标准化了任意元数据集的描述,它要求用户跨越多个工业和操作环境而使用同一种方式读取数据。 
  • 仓库包含一些杂类脚本,这些... 每个脚本未列出perl , awk , wget等标准要求。 许多脚本可以不带任何参数运行, -h或--help获取使用信息。 我对使用制表符(4)代替空格所造成的致命罪恶感到内,所以请当心。 后备
  • (二)仓库安全管理的要求 112 二、仓库的安全保护 113 (一)仓库保卫工作的主要任务 113 (二)警卫工作的主要任务 113 (三)仓库治安保卫措施 114 三、仓库消防安全 115 (一)常见的火险隐患 115 (二)基本的灭火方法 116 ...
  • 仓库的根目录运行CLI命令npm run dist 。 如果您尚未安装NodeJ 目前,此应用程序仅作为基于命令行的程序进行分发。 为了运行它,您必须安装 。 之后,您可以从存储库的根目录运行CLI命令npm run dist 。 假设...
  • ckanext-saml-源码

    2021-02-27 12:27:48
    添加使用标准从其他来源(称为 )登录的功能。 您的实例显示为 。 此扩展适用于python 3.6+ 要求 ckanext-saml使用python3-saml库来向IdP发出请求并从中返回响应。 Github仓库可以在找到。 安装 在开始安装之前,...
  • Mysql 数据库是一种关系型数据库管理软件,关系型数据库特点是将数据库保存在不同的二维表(Excel)中,并且将这些表放入不同的数据库中,而...源码安装mysql,其中两个版本对编译环境要求1.mysql从5.5版本开始,...
  • Oracle商务手册易燕海

    2012-11-23 22:57:17
    3. Oracle数据库11g企业版(Oracle Database 11g Enterprise Edition )为关键任务的应用程序(如大业务量的在线事务处理 (OLTP) 环境、查询密集的数据仓库要求苛刻的互联网应用程序)提供了高效、可靠、安全的...
  • 序号设备名称技术参数数量1大数据工具-1基于开源、开放的标准,拥有第三方生态环境支持,包括主流的数据仓库、ETL工具、可视化、数据挖掘等工具。大数据平台企业数据工程版软件及技术服务,不接受免费版本产品。除了...
  • 位图索引是为数据仓库/即席查询环境设计的,在此所有查询要求的数据在系统实现时根本不知道。位图索引特别不适用于OLTP系统,如果系统中的数据会由多个并发会话频繁地更新,这种系统也不适用位图索引。 位图索引...

空空如也

空空如也

1 2 3 4 5
收藏数 96
精华内容 38
关键字:

仓库环境要求标准