初学者的持续集成和交付(DevOps)

目录

介绍

背景

先决条件

第1步——创建部署组

步骤2——在内部部署服务器中安装VSTS代理

第3步——配置构建操作

第4步——设置发布

第5步——启用CI和CD

您可能会发现一些有用的提示

1.请尽可能多地使用变量

2.管理连接字符串和其他web.config变量

3.包含部署的附加文件夹(添加文件以构建项目)

4.部署前备份文件

5.部署前备份数据库

6.配置自动电子邮件触发器以进行批准


使用VSTSVisual Studio Team Services)持续集成和交付

介绍

DevOps是软件开发和操作(DevOps)的组合,它强烈支持软件开发过程中所有步骤的自动化。这将使软件开发团队能够实现更快的交付,更稳定的操作环境,最小的人为错误,更少的维护成本和更多优势。

例如,如果要构建一个在带有负载均衡器的10Web服务器上运行的企业级应用程序,那么您的实时部署会如何?那么,答案就在这里!!

早些时候,DevOps仅限于一个名为DevOps工程师的团队。但是现在是时候开始像你这样的软件工程师了!

背景

有几种工具可用于持续集成和持续交付。JenkinsVisual Studio团队服务在这些工具中更为出名。在本文中,我将重点介绍如何使用VSTS和基本步骤来完成此操作。在我的下一篇文章中,我将重点介绍VSTS中的更高级功能。

使用VSTS进行Azure部署的文章很多。但是使用VSTS进行内部部署的指南和文章仍然很少。因此,我将重点关注本地部署。

我假设大家都熟悉Visual Studio团队服务的基本操作,包括git 存储库维护。

先决条件

应该在服务器上安装.NET 3.5,因为Web部署将使用需要.NET 3.5才能执行的Msdeploy

如果仍未安装,请在管理员模式下运行以下Powershell脚本。

dism.exe /online /enable-feature /all /featurename:NetFX3 /Source:D:\sources\sxs

1步——创建部署组

设置部署组后,它可能具有数据库服务器和Web服务器。然后我们可以在每台机器上安装部署代理。之后,它将启用并行部署。

首先,导航到VSTS中的选定项目。然后打开构建和发布选项卡,并根据给定的图像选择新的部署组。最后,单击创建创建自己的部署组。

https://www.codeproject.com/KB/Best-Practices/1250651/Deployment.PNG

步骤2——在内部部署服务器中安装VSTS代理

只需将此PowerShell脚本复制并粘贴到本地服务器中(PowerShell应以管理员模式运行,并确保在复制脚本之前标记在脚本中使用个人访问令牌进行身份验证)。它将生成个人访问令牌以验证和鉴定Web服务器。

这是脚本,其包含需要运行、安装和配置部署代理所需的任何机器。由于此脚本具有一些GitHub URL,因此需要在本地服务器上下载并安装某些文件。因此,它应该有互联网连接。

运行此脚本后,部署代理将安装到本地服务器,它将运行并通过Windows服务进行侦听。

https://www.codeproject.com/KB/Best-Practices/1250651/SercerSetup.PNG

运行上面的代码段时,PowerShell会提出几个问题。

为代理输入部署组标记的第一个问题——只需输入几个标记

输入组合用户帐户的第二个问题——使用默认帐户

然后再次移至您的VSTS帐户并检查部署组中的目标标签。然后,您可以看到在本地服务器中输入的标记。

最后,如果您正确执行这些步骤,现在您的部署组应处于联机状态!

https://www.codeproject.com/KB/Best-Practices/1250651/DeploymentGroupOnline.PNG

3步——配置构建操作

在这一步中,我们将在VSTS中配置第一个构建,这将主要基于MsBuild

导航到构建和发布部分并选择构建选项卡。然后根据给定图像创建新构建。

https://www.codeproject.com/KB/Best-Practices/1250651/build1.PNG

选择VSTS Git选项(或相关的源代码控制)和您的团队项目。

https://www.codeproject.com/KB/Best-Practices/1250651/build2.PNG

在下一个屏幕中选择ASP.NET作为模板。

https://www.codeproject.com/KB/Best-Practices/1250651/build3.PNG

现在,您将最终获得ASP.NET Web部署的基本功能。

但根据您的项目要求,这些基本功能对您来说还不够。如果您需要更多功能,可以从市场搜索合适的插件。(https://marketplace.visualstudio.com/vsts)他们中的大多数现在免费提供。但是,如果您无法找到合适的插件,您可以编写自己的插件。

在本文中,我将使用npmgrunt作为附加功能。因为在我的项目中,我已经用于grunt JSCSS压缩,使用更少的文件创建CSS文件,并使用penthouse生成上面的折叠内容,以映射Google速度洞察要求。(https://developers.google.com/speed/pagespeed/insights/

所以,我的构建操作需要一些grunt命令。

由于我们正在讨论初学者级别,因此我们将处理此构建过程中的大多数默认功能。

选择Phase1功能,然后选择Hosted VS2017作为代理队列。您可以使用任何首选名称重命名Phase1

https://www.codeproject.com/KB/Best-Practices/1250651/build4.PNG

除此之外,可以使用这些默认值继续构建。根据项目要求,您可以更改值。

正如我上面提到的,我会额外添加npmgrunt来完成我的生成定义。请注意,这是一项附加功能,除非您在项目中使用grunt命令,否则可能不需要使用此功能。

https://www.codeproject.com/KB/Best-Practices/1250651/build5.PNG

只需使用命令作为install而不是使用npm

https://www.codeproject.com/KB/Best-Practices/1250651/build6.PNG

按照相同的步骤安装grunt并添加不带“grunt”前缀的grunt命令。(确保在插件中添加Grunt文件路径

然后,您可以根据需要通过拖放重新排序这些单独的任务。见下图。

https://www.codeproject.com/KB/Best-Practices/1250651/build8.png

根据图像,您可以看到构建管道。下面的任务在该管道中配置,它将一个接一个地运行。

  • 使用NuGet - 将安装nuget来构建服务器
  • NuGet还原 - 将根据package.config使用所需的包恢复nuget
  • Npm安装 - 将安装npm(可选)
  • Grunt生产 - 将运行grunt配置中提到的任务(可选)
  • 构建解决方案 - 构建解决方案。您可以在此处使用默认的MSBuild Arguments
  • 测试组件 - 将运行所有单元测试。如果您有任何测试项目,请在此处配置路径。
  • 发布符号路径 - 将发布项目。默认值将能够发布您的项目。
  • 发布项目 - 将在此步骤中创建发布文件夹。如果您感兴趣,可以更改发布路径或项目名称(它将包含变量和构建项目作为zip文件)。无论如何,默认值将能够发布项目。

现在您已完成部署过程。只需保存所有设置并排队新构建并检查它是否正确构建。如果出现错误,则必须先进行调试并计算出来,然后再继续执行下一步。

4步——设置发布

现在是时候设置第一个自动发布了。转到构建和发布选项卡,然后选择发布菜单。然后选择创建发布定义并根据给定的图像单击IIS网站和SQL数据库部署

https://www.codeproject.com/KB/Best-Practices/1250651/Release1.PNG

然后你可以像betalive等输入环境名称等。

https://www.codeproject.com/KB/Best-Practices/1250651/Release2.PNG

然后,您将获得发布管道配置菜单。选择任务选项卡,您需要在此处完成一些配置。

然后,您应选择“IIS网站作为配置类型。

任何名称作为网站名称。

您的网站应用程序池名称作为给定图像的应用程序池名称。

https://www.codeproject.com/KB/Best-Practices/1250651/Release3.PNG

然后选择IIS部署选项卡并将其填入必填字段。

部署组(您在前面的步骤中已创建的部署组)

如果您感兴趣,请输入标签,然后使用默认值保存表单以保留其余字段。

配置完成后,转到IIS Web App管理部分。

  • 配置类型(IIS网站)
  • 输入网站名称(任意名称)
  • 操作(创建或更新)
  • 物理路径(D:\Projects\Applications\TestApp等)
  • IIS应用程序池(当前应用程序池详细信息

https://www.codeproject.com/KB/Best-Practices/1250651/Release6.PNG

现在你几乎完成了配置。只需几步即可实现持续集成。

几乎没有其他任务,例如将文件复制到:备份存档$Build.BackUpPath运行Sql命令

我们将在本文后面讨论它们,它们不是基本部署所必需的。

5步——启用CICD

从导航中选择构建,然后根据下面的给定图像选择编辑定义任务:

https://www.codeproject.com/KB/Best-Practices/1250651/Release7.PNG

然后选择触发器选项卡,只需选中启用持续集成复选框。如果您有兴趣启用分支智能禁用此功能,您也可以在此处执行此操作。

启用此功能后,它将在您提交特定分支时自动触发。

https://www.codeproject.com/KB/Best-Practices/1250651/Release8.PNG

然后,您需要设置释放触发器。然后它将在驻地服务器上进行部署。

因此,导航到发布菜单并进行编辑。

然后选择管道选项卡,并根据图像单击持续部署触发器图标。

最后,启用Continuous部署。如果您有兴趣,也可以添加分支过滤器。

https://www.codeproject.com/KB/Best-Practices/1250651/Release9.PNG

!!您刚刚完成了第一个持续集成项目......

现在是时候测试你的第一个项目了。请对您的代码进行一些小的更改并提交并等待部署完成。就这些了!

您可能会发现一些有用的提示

1.请尽可能多地使用变量

从长远来看,它可能会有所帮助并保持这些配置。

BuildRelease configuration选项卡中提供的变量。使用前缀为'$'符号的变量。

例如: $(Build.ProjectPath)

https://www.codeproject.com/KB/Best-Practices/1250651/Release11.PNG

2.管理连接字符串和其他web.config变量

根据上面的示例,您只需要将连接字符串名称作为变量名称和连接字符串添加为release variable部分中的值。它将根据变量自动替换web.config值。

<add name="umbracoDbDSN" connectionString="server=xxxx;database=yyyy;
user id=zzz;password='aaa'" providerName="System.Data.SqlClient" />

这是我们的web.config所以,

变量名=> umbracoDbDSN

=> server=xxxx;database=yyyy;user id=zzz;password='aaa'

3.包含部署的附加文件夹(添加文件以构建项目)

例如,如果您需要在Conten \minified文件夹中部署所有文件,但如果仍未部署,请打开.csproj文件并添加以下代码(请根据您的要求更改值)。

<Content Include="Content\minified\**\*.*">
      <CopyToOutputDirectory>Always</CopyToOutputDirectory>
</Content>

4.部署前备份文件

根据给定的图像将复制文件任务添加到您的版本定义中。然后输入如下值。

  • 源代码文件夹(您的文件路径)
  • 内容(需要复制的文件包含在上述路径中,例如:bin \ *
  • 目标文件夹(目标文件夹)

https://www.codeproject.com/KB/Best-Practices/1250651/Release13.PNG

5.部署前备份数据库

根据给定的图像将运行Sql命令任务添加到您的版本定义中。

  • 服务器名称(数据库实例名称)
  • 数据库名称(您的数据库名称)
  • SQL命令(请更改值)
BACKUP DATABASE [yyyy]
  TO DISK = 'F:\SQLbackup\$(Build.BuildId).bak' 
GO

SQL Server登录(数据库用户名)

SQL Server身份验证密码(用户密码)

https://www.codeproject.com/KB/Best-Practices/1250651/Release14.PNG

6.配置自动电子邮件触发器以进行批准

可以选择部署前后批准。您可以在此处输入用户或用户组。如果添加了用户组,则只有一个人的批准才足以完成部署。

https://www.codeproject.com/KB/Best-Practices/1250651/Release16.png

 

原文地址:https://www.codeproject.com/Tips/1250651/Continuous-Integration-and-Delivery-for-Beginners

  • 0
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
刚刚发布的ThoughtWorks技术雷达 建议技术团队“暂缓或谨慎”使用反模式“CI theatre(伪CI,可以理解为不完整的持续集成)”。 “伪CI”描述的是实践持续集成(CI)过程中的一些错觉,然而这些并不是真正的CI实践。 基于持续集成,我和同事 Emily Luke做了一些研究, 我将分享伪CI是什么样的,为什么我们建议你“暂缓或谨慎使用”,以及预防伪CI的方法。持续集成我最喜欢的CI定义来自于continuousdelivery.comCI开发人员定期(至少每天)将他们所有的工作集成到主干(也称为主线或主干分支)这个引用中暗含了CI实践的两个基本原则。第一个是“把他们所有的工作集成到主干”;第二个是“至少每天”。对于CI还有一系列其他原则和实践,例如:将所有内容都检入您的代码库,构建每个提交,自动化构建,保持快速构建,并有可以自我验证的代码, 还有Martin Fowler 关于持续集成的评论中的可视化故障并立即修复故障等。我个人认为 每天至少检入代码到主干分支一次 是CI的基础。没有达到这一点就只是伪CI而不是真正意义上的CI。伪CI是什么样的?这是我们调研到的一个故事,一位经验丰富的开发人员(让我们称他为David)来自湾区的一个中型创业公司,每周有两次产品交付。 David说他的组织正在践行CI,他说:“是的,我们用Circle CI”,他描述了一个具有挑战性的场景,曾经在一个分支上工作了一段时间,大约修改了100个文件和7000行代码,然后在代码审查阶段就开始招架不住了,因为他要向他的同事解释所有的代码变更的原因。“最具挑战性的事情是你最终要将一大堆功能集中到一个提交里,因为它们都是这个组件的一分”,他解释说:“我希望有一个更好的方式来分解这些提交,因为很难把所有事情(变更历史)记在脑子里。”如果这个情况你听起来很熟悉,那么你也在做伪CI。 如果有下面的这些场景,那么你们就是在做伪CI:当有人问起你们在实践CI吗? 如果你说我们有一个CI服务器并且我们使用X工具在我们的调查中,只有10%的参与者承认有CI服务器与CI践行不一样。 相反,90%的个人表示他们正在践行CI,无论他们是否有专门从事CI的基础知识。 所以简单的认为只要有一个CI服务器就是“在做CI”,这就清楚地表明是在做“伪CI”。使用长期开发分支,但不会定期检入master主干在David的故事中,他们并没有实践每天检入master主干,这就是“伪CI”的标志。 这是我们在调研中常看到的一种模式,其中团队在master主干上运行CI,但不频繁构建,也不是每天都在提交。 或者他们在分支上运行CI,但不会频繁的集成到master主干。 只对特性分支运行CI,其实应该称之为持续隔离(continuous isolation)才对.合并分支时感到焦虑和疲惫真正的持续集成要把代码所有者的责任意识扩展到整个团队。 这改变了团队内人员的观点以及他们对失败构建的态度。 不再是“我的宝贵的分支”,或是“我的错误导致构建被破坏”,而是“我们的代码”和“我们的失败”。David遇到焦虑和疲惫的事实清楚地表明,他忽略了CI的一个重要的优势:持续反馈和代码集体所有权。伪CI还有更多的一些现象,虽然我们发现有一些并不那么常见,但它们仍然存在一些问题,构建的时候,仅有极少的测试覆盖允许构建长时间处于失败状态虽然David的团队引入了一个备受尊崇的CI工具和常见的流程,如特征分支和代码审查,但他们并没有实施全套CI实践,因此错过了许多好处。 我们遗憾的发现,在我们的研究的组织中90%发生了这种情况。一些组织实施伪CI中反而错失了CI的主要优势 - 快速反馈,代码集体所有权,并准备达成持续交付如何避免,预防和解决伪CI的问题?如果您确定可能正在遭受伪CI之苦,则可以通过三种方式来解决问题并进行持续改变。1. 提交更频繁回到根本,尽量频繁地提交,每天至少提交一次应该是最低目标。 如果你还没有开始做CI,这就是你可以开始的地方,即使你在做CI,依然会有改进的空间。我喜欢“频率降低难度”的说法。 往往我们在做一些事情时,任务变得越小,则其更容易被实现。 持续集成就是是一个典型例子。 我的建议是要更加频繁地检入你的代码到代码库并且将开发分支集成到主干分支,至少每天集成一次”。2. 基于主干分支开发有很多论坛在讨论基于主干还是基于开发分支进行开发,我不想讨论那些血淋淋的细节。 然而,在我们的调研中,当我们与一些曾经在实践CI过程中感到痛苦的人交谈时,没有引入主干开发的团队对此有更深刻的感受。 DevOps现状调查报告-2016 还发现,基于主干开发和持续集成是达成持续交付的关键因素,同时也能建设更高效能的团队。基于主干的开发肯定会有一定的挑战,但它可以把问题提前暴露出来,而不是要等到代码合并、代码审查甚至到延迟发布的时候。如果你想达到更好效果的CI和CD,我建议在主干上做开发,或者如果你更愿意使用短周期的临时分支(合并到主干之前不到一天)进行开发,那么最好同时不要超过三个以上的活跃分支。3. 自动化自动化是做好持续集成的基石,所以如果你还没有自动化一切,现在是开始的好时机。 如果你认为已经实现了所有自动化的功能,那么每次有人手动地做任何事情超过一次,便要问自己“这个为什么不能自动化”? 我已经观察到自动化不仅可以帮助您在CI中变得更好,还可以帮助您开始持续交付。总结现在你知道什么是伪CI了,如果你的团队正在这么实践伪CI,那么你可以阻止这种情况继续发生了。 如果您仍然感到困惑,我建议你在Martin Fowler的博客“CI Certification test”做一个测试, 以确认你的组织是否正在做可靠的CI。 如果你通过了CI测试,那太好了,现在是考虑您是否准备好实施持续交付的时候了。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值