如何将构建 (java) 设为“独立于 CM” 尽可能？ （CM=配置管理器）
我一直在考虑让我处理的项目构建之一尽可能“独立”于我（CM）。 我的意思不仅仅是通过脚本/工具实现自动化——尽管它肯定包括它。 这是一个非常混乱的项目，因此“完全”自动化是不现实的。
这就是我的目标：
任何人都应该能够进行构建（通过一些自动化和一些文档/指南）——例如——新手 CM，甚至是没有 CM 经验的开发人员。
我的第一个想法是通过以下方式实现这一目标：
确定构建请求流程（通过构建表单捕获构建所需的所有详细信息，这样就不会因为它在某人的头脑中而落入裂缝）
简化构建步骤，以便可以将它们作为命令序列捕获在简单的文档中- 受过训练的猴子应该能够运行构建（好吧..不是侮辱，而是 - 你明白了:-) ）
充分利用该工具的功能（阅读 ANT，SVN），这样提前发现潜在问题，并有助于在出现故障/问题时提供更好的警报。
可以自由地生病或偶尔休假，而不会每次我提到休息几天时项目经理就会惊慌失措。 :-)
我很高兴能有一些想法和想法来帮助我朝这个方向发展。 谢谢大家！
I have been thinking of making one of the project builds I handle, as "independent" of me(CM)as I possibly can. By this I dont just mean automation via scripts/tools - although it definitely includes it. This is a project subject to much chaos and so "total" automation would not be realistic.
Here is what I'm aiming for:
Anybody should be able to do the build (with some automation and a bit of documentation/guidelines) - for instance - a newbie CM, or even a developer with no CM experience.
My first thoughts are to achieve this by:
Nailing the Build request process (via build forms which capture ALL details required for the build so that nothing falls down the cracks just because its in someone's head)
Simplifying the build steps so that they can be captured in a simple documentation as a sequence of commands - a trained monkey should be able to run with the build (well.. not hurling insults but - you get the idea :-) )
Using the tool's features to the hilt (read ANT,SVN) such that the potential issues are caught well in advance and also help provide better alerts in case of failures/issues.
Having the freedom to fall ill or take those occasional holidays without the project manager getting panic attacks everytime i mention a couple of days' off. :-)
I'd be glad to have some thoughts and ideas to help me in this direction. Thanks all!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在 Urbancode 中，我们将此称为“Bob the Builder”反模式。 好消息是鲍勃（你）想要摆脱困境。 当建造人员不能去度假或生病时，过程的某些部分就会停止，这确实是一个不可接受的问题。 如果我是一个投注者，当你开始将流程简化到“受过训练的猴子”级别时，你会想知道为什么你要花时间做这些死记硬背的事情，而你很聪明并且实际上可以添加某处有价值。
我们书中的“建造者鲍勃”综合症的症状是：
我们告诉我们的 AnthillPro 客户将所有此类内容推入他们的自动化中。 拥有两种使用不同机器、不同构建号等的构建类型应该不是问题。
第一步是简化流程。 尽可能消除复杂性，以便您可以深入了解“受过训练的猴子”流程。 一旦你有了接近这个目标的东西，用计算机代替猴子就很容易了。
我会给出更具体的建议，但我认为你没有告诉我们除了混乱之外复杂性从何而来。 有时在这种情况下，您需要攻击混乱和不良的做法。 您是否正在执行“源代码中的基线以及这两个文件和这三个文件？”的构建？ 这会很棘手，可能需要 CMer 参与其中。 想办法禁止它。 将其替换为“创建一个分支，并对该分支进行特定更改”使得该猴子可以构建构建。
您应该能够认为这些更改是高风险的。 即使你很优秀，你也会有糟糕的日子，并且希望尽可能地消除人为错误。 同时，如果您希望更快地响应开发人员和自助服务（这可能是开发和管理人员想要的），那么某些事情将需要变得可自动化/可猴子化。
在此期间拥有更好的形式可能会很好，并且很好地使用你的工具总是好的，但我会非常积极地解决“受过训练的猴子”问题。 任何不能由受过训练的猴子（或计算机）完成的事情都应该成为离开该过程的候选者。 一旦您将其降低到“受过训练的猴子”状态，就可以实现构建自动化，这样您和开发人员都不需要成为猴子。 这会将您的角色从“构建者鲍勃”更改为“构建系统所有者鲍勃”。
At Urbancode, we refer to this as the "Bob the Builder" anti-pattern. The good news is that Bob (you) wants to get out of the loop. When the build guy can't go on vacation or get sick without parts of the process grinding to a halt, there really is an unacceptable problem. If I'm a betting man, as you start the process of simplifying the process down to "trained monkey" levels, you'll wonder why you're spending your time doing this rote stuff when you're smart and could actually be adding value somewhere.
The symptoms of "Bob the Builder" syndrome in our book:
We tell our AnthillPro customers to push all of this kind of stuff into their automation. Having two build types that use different machines, different build numbers, etc shouldn't be a problem.
The first step is to dumb down the process. Drive as much complexity out as possible so that you can get down to the "trained monkey" process. Once you have something approaching that, replacing the monkey with a computer is pretty easy.
I'd give more specific advice, but I don't think you've told us where the complexity comes from, other than chaos. Sometimes in this situation you need to attack chaotic and bad practices. Are you doing builds that are "This baseline in source code and those two files and these three files?" That would be tricky and probably need a CMer in the loop. Find a way to forbid it. Replacing that with "Create a branch, and make specific changes to that branch" makes constructing the build doable by that monkey.
You should be able to argue for those changes as high risk. Even though you are good, you will have bad days and want to take human error out of the equation as much as possible. At the same time, if you're shooting for faster response to the developers and self service (which presumably development and management want) some things will need to be made automateable / monkeyable.
Having better forms can be good in the interim, and using your tools well is always good but I would attack the the "trained monkey" problem pretty aggressively. Anything that can't be done by a trained monkey (or a computer) should be a candidate for leaving the process. Once you have it down to "trained monkey" status, get your build automation in place so neither you nor the developers need to be monkeys. That changes your role from "Bob the Builder" to "Bob the Build System Owner".
如果那样比通过脚本（可能是 ant、bash、maven 或其他脚本）一步运行构建是可能的。 这应该是目标，所以基本上任何人都可以进行构建。
If that is possible than it should be possible to run the build in one step via a script (mayy it be an ant, bash, maven or whatever script). That should be the goal, so basically anybody can do the build.
开发构建过程的目标应该是这样的：
如果如果你做不到这一点，那么你的构建过程仍然不够好。
如果您认为您无法实现它，请详细描述除了该列表之外您还需要执行哪些操作是图灵完备机无法执行的。
通常没有这样的点。 只是缺少工具/知识/动力。 我个人发现，这样做比描述为什么不能这样做更容易。
祝你好运。
The goal of developing a build process should be this:
If you can't do that, then your build process is still not good enough.
If you think that you can't achieve it, then describe in detail which actions you need to do in addition to that list are not possible to do by a turing-complete machine.
Usually there isn't such a point. It's only the missing tools/know-how/motivation. I, personally, found out that it's easier to do this, than to describe why it can't be done.
Good luck.