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

我们有4个不同的环境：我们如何改进我们的部署和构建系统？

分期
开发
用户验收
直播

我们使用TFS，拉下最新的代码和代码了。
当他们完成某项功能时，开发人员将其更改单独上传到暂存。如果网站稳定（由非常宽松的测试确定），我们将更改上传到Dev，然后上传UserAcceptance，然后进行直播。

我们在源代码控制中根本没有使用build/tags。

我应该告诉管理层什么？据我所知，他们似乎认为没有问题。

来源

2009-05-26 Blankman

告诉他们，如果你使用的是一个非常昂贵的软件的关键特性，他们花了很多钱，那么告诉什么代码什么时候被推出将是微不足道的。这意味着如果引入了一个微妙的错误，并通过了用户验收测试，那么就可以通过区分这两个版本来确定发生了什么变化。

来源

2009-05-26 20:34:03

不知道我跟着你抱歉。 – Blankman 2009-05-26 20:35:15

“你花了很多钱买了很贵的软件”（注意）“关键功能”（我会说“标签”，但我不想让你的眼睛因说出技术喋喋不休而被淹没）“如果你正在使用“（这是一个可操作的建议）”这对于等等而言是微不足道的“ （好处或卖点） – ChrisW 2009-05-26 20:49:22

谁的管理？他们离你多远？

I.e.如果你只是一名庄家开发人员，而你的经理是高级开发人员，那么你会找到另一份工作。如果您是高级开发人员，而您的经理是CIO类型，即实际运行业务......那么您的工作就是改变它。

来源

2009-05-26 20:38:40

使用标记最重要的部分之一就是您可以回滚到特定时间点。将其视为图像备份。如果部署错误，您可以安全地假设您可以“回滚”回到以前的工作版本。另外，开发人员可以快速获取TAG（dev，prod或其他），并将其部署到他们的开发PC ...我一直使用的功能来调试生产问题。

来源

2009-05-26 20:39:18 northpole

如果这对你有好处，你可以成为贵公司的Continuous Integration冠军。你可以做一些关于CI with TFS的良好流程的研究，写出一个建议的解决方案，向你的开发者和直接经理人传授，并用他们的意见对它进行修改，并将其发布给管理层。或者你可以坐在那里什么都不做。

我一直在管理很长一段时间。我总是很感谢能够识别问题并提出深思熟虑的解决方案的人。

来源

2009-05-26 20:46:42

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

您还需要告诉管理层您认为所做测试的级别不足。对于一个组织来说这不是一个独特的问题，他们可能会说他们已经知道了。虽然没有提到它，但并没有等待一个重大问题的到来。

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

来源

2009-05-26 20:49:40

什么是的问题？正如你所说，你不能分辨管理层是否看到问题。也许他们不会！告诉他们你认为目前的问题以及你会建议如何解决问题。问题的关键在于“我们目前的流程已经失败了3次，实施这个新流程会将这些失败次数降低到10次之一”。

管理层需要看到改进：降低成本，增加利润，缩短时间，减少资源使用。 “因为这是广泛使用的最佳实践”还不够。也不是，“因为它让我的工作更轻松”。

管理层往往没有意识到问题，因为每个人都太害怕说什么或者认为他们不可能看不到问题。但你的世界与他们的世界是不同的世界。

来源

2009-05-26 21:23:25 KnownIssues

我看到至少两个大问题： 1）开发人员自己加载更改。所有更改应该来自源代码管理。你有没有遇到过某些人做了一些改变，但没有进入源代码控制，然后在下一次部署时被意外删除的时间？花了多少时间（金钱）试图弄清楚那里出了什么问题？

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

我致力于持续集成和部署解决方案AnthillPro。我们如何通过TFS解决这个问题，就是根据日期时间戳（当有人按下“Deliver to Stage”按钮时）从TFS中检索新代码。

这给了你大部分（所有？）追踪你使用标签的必要性，而不必实际去标记东西。系统只记录时间戳，并且通过测试环境每次推送代码都与已知的代码快照关联。我们也有将标签作为构建过程的一部分的客户。作为第一个提到的海报 - CI是一件好事 - 少工作，更多可追溯性。

来源

2009-05-27 14:25:33 EricMinick

如果你已经有TFS，那你就快到了。

我正在使用TFS进行源代码管理。我们与Dev/Stage/Prod有类似的设置。我把它放在自己身上来安装一个构建服务器。一旦完成，我添加了自动部署到我的项目开发的能力，并告诉其他人一些关于它。最初的招待会温暖。

后来我加入了TFS部署者，并设置为自动部署良好的开发版本。

在此期间，主要开发者群体不断与“在部署到舞台或制作之前获得最新成果？问题;我的东西工作顺利。相信我，管理层和其他开发者注意到了。

现在（6个月），我们有一个书面规则，您甚至不允许在Visual Studio中使用Publish命令。一切都通过CI构建和部署。在转向生产时，我们的生产组从生成服务器中提取适当的副本。我甚至对如何进行网络测试的QA小组进行了培训，并且我们正在慢慢地将自动化测试集成到整个文件中。

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

我建议你也这样做。开始使用它，然后展示让其他人参与的好处。

来源

2009-05-28 23:13:25 NotMe

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

回答

相关问题