我们如何改进部署和构建系统?

时间:2009-05-26 20:26:19

标签: asp.net tfs build-process

我们有4种不同的环境:

  • 分段
  • 开发
  • 用户接受

我们使用TFS,下载最新的代码和代码 完成功能后,开发人员会将其更改单独上载到Staging。如果网站稳定(通过非常宽松的测试确定),我们会将更改上传到Dev,然后是UserAcceptance,然后直播。

我们根本没有在源代码管理中使用构建/标记。

我应该告诉管理层什么?就我所知,他们似乎并不认为存在问题。

8 个答案:

答案 0 :(得分:5)

如果对您有好处,您可以成为贵公司的Continuous Integration冠军。您可以对CI with TFS的良好流程进行一些研究,撰写提议的解决方案,将其传播给您的开发人员和直接管理人员,根据他们的意见进行修改并将其推荐给管理层。或者你可以坐在那里什么也不做。

我已经在管理层工作了很长时间。我总是感谢能够识别问题并提出经过深思熟虑的解决方案的人。

答案 1 :(得分:1)

谁的管理?他们离你多远了?

即。如果你只是一个pleb开发人员而你的经理是高级开发人员那么找到另一份工作。如果您是高级开发人员,并且您的经理是CIO类型,即实际运营业务......那么您的工作就是更改它。

答案 2 :(得分:0)

告诉他们如果你使用非常昂贵的软件的一个关键功能,他们花了很多钱,那么告诉什么代码被推出是很简单的。这意味着如果引入了一个微妙的错误,它会通过用户验收测试,那么就可以将两个版本区分开来以找出发生了哪些变化。

答案 3 :(得分:0)

使用TAGS最重要的部分之一是您可以回滚到特定时间点。将其视为图像备份。如果部署了一些不好的东西,你可以放心地假设你可以“回滚”到以前的工作版本。

此外,开发人员可以快速获取TAG(dev,prod或其他)并部署到他们的开发PC ......我一直使用的功能来调试生产问题。

答案 4 :(得分:0)

因此,您需要有人告诉其他开发人员,他们必须在每次构建完成时标记其代码并增加版本计数器。你为什么不能这样做?

您还需要告诉管理层您认为完成的测试级别不够。对于一个组织来说,这不是一个独特的问题,他们可能会说他们已经知道了。提及它没有坏处,而不是等待一个重大问题到来。

对于进行构建或自动构建过程的个人而言,这取决于您是否真的需要基于开发人员的数量以及构建的频率。

答案 5 :(得分:0)

是什么问题?正如您所说,您无法判断管理层是否看到了问题。也许他们没有!告诉他们您认为当前的问题以及建议您解决问题的方法。问题必然是“我们目前的流程已经失败了10次,并且实施这一新流程会将这些失败减少到10次中的1次”。

管理层需要看到以下方面的改进:降低成本,减少利润,减少时间,减少资源使用。 “因为它被广泛使用的最佳实践”是不够的。也不是,“因为它使我的工作更容易”。

管理层通常不会意识到问题,因为每个人都害怕说不出话来或者假设他们不可能看不到问题。但是你的世界与他们的世界不同。

答案 6 :(得分:0)

我至少看到两个大问题: 1)开发人员自己加载更改。所有更改都应来自源代码管理。您是否遇到过某人进行了更改而进入生产但从未进入源代码管理然后在下一次部署时被意外删除的时间?花了多少时间(金钱)来弄清楚那里出了什么问题?

2)缺乏明确的推广模式。看起来你们正在改变环境而不是“构建”。关键的区别在于,如果两个更改在UAT中工作得很好,因为它们的交互方式,如果只有一个更改被提升为生产,那么它可能会在那里发生变化。促进一致的代码 - 无论是通过标记它还是通过拉动整个Web应用程序并推广zip文件 - 都应该减少问题。

我致力于持续集成和部署解决方案AnthillPro。我们如何使用TFS解决这个问题是根据日期时间戳(当有人按下“发送到舞台”按钮时)从TFS检索新代码。

这为您提供了大部分(全部?)使用标签的可追溯性,而无需实际标记。系统只记录时间戳,并且每次通过测试环境推送代码都与已知的代码快照相关联。我们还有客户在构建过程中放置​​标签。正如第一张海报所提到的 - CI是一件好事 - 工作量少,可追溯性更强。

答案 7 :(得分:0)

如果你已经拥有TFS,那么你几乎就在那里。

我所在的地方仅使用TFS进行源代码管理。我们与Dev / Stage / Prod有类似的设置。我自己动手来安装构建服务器。完成后,我添加了为我的一个项目自动部署到dev的能力,并告诉其他几个人。最初接待是温暖的。

后来我添加了TFS Deployer并将其设置为自动部署好的开发构建到舞台。

在此期间,主要开发人员一直在与“在部署到舞台或制作之前获得最新信息?”进行斗争。问题;我的东西工作顺利。相信我,管理层和其他开发者都注意到了。

现在(6个月后),我们有一条书面规则,即使您无法在Visual Studio中使用“发布”命令。一切都通过CI构建和部署。移动到prod时,我们的生产组从构建服务器中提取适当的副本。我甚至培训了我们的QA小组如何进行网络测试,我们正在慢慢将自动化测试整合到整个社交网中。

这个漫步的重点是花了一段时间。但更重要的是,它只是因为我愿意与它一起运行并显示结果。

我建议你这样做。开始使用它,然后展示让其他人加入的好处。

相关问题