如何从“奥术集成”迁移到“奥术集成” 持续集成？
现在，我正在进行的一个项目已经达到了一定程度的复杂性，需要多个步骤（实际上它变得神秘！）才能生产出完整/可用的产品。 不幸的是，我们一开始并没有持续集成的心态，所以你可以想象它有时会很痛苦，而有时我很容易浪费半天时间来尝试获得干净/经过测试的构建。
无论如何，作为任何大型项目，它都由许多不同语言的许多组件组成（例如，不仅是企业风格的 Java 或 C#），以及许多图形和文本资源。 现在的问题是，当我寻找持续集成时，我总是找到假设人们从头开始一个新项目的最佳实践和技术。 然而，这不是一个新项目，所以我想知道有哪些好的资源可以主动开始从 Arcane Integration 迁移到持续集成:)
提前致谢！
Right now a project I'm working on has reached a level of complexity that requires more than a few steps (actually its become arcane!) to produce a complete/usable product. And unfortunately we didn't start out with a Continuos Integration mindset, so as you can imagine its kind of painful at times, and at others I can easily waste half a day trying to get a clean/tested build.
Anyways as any HUGE project it consists of many components in many different languages (not only enterprise style Java or C# for example), as well as many graphical, and textual resources. Now the problem is that when I look for Continuos Integration, I always find best practices and techniques that assume one is starting a new project, from the ground up. However this isn't a new project, so I was wondering what are some good resources to proactively start migrating from Arcane Integration towards Continuos Integration :)
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
这里只需两个简单的（哈哈）步骤。
这些步骤可以一次完成一个，有点像一条可遵循的路径。 您将在每个阶段获得收益。 例如，如果您根本不使用源代码管理，那么仅将代码放入源代码管理（不做任何其他事情）就是向前迈出的一大步。 此外，如果没有自动化测试，那么开发人员就无法运行它们 - 但他们仍然可以获得先前的提交并让编译器检查他们的工作。
如果你能做到所有这些，你就会到达一个理智的地方。
目标是可重复的构建过程和开发人员，了解他们的更改如何影响构建和其他开发人员。
然后，您可以通过建立更高的合规性来获得好处：
Here it is in two simple (hah) steps.
These steps can be done 1 at a time, sort of a path to follow. You'll get benefits at each stage. For example, if you aren't using source control at all, just getting the code into source control (without anything else) is a big step forward. Also, if there are no automated tests, then developers can't run them - but they can still get the prior commits and get the compiler to check their work.
If you can do all of these, you'll get to a nice sane place.
The goals are repeatable build processes and developers that are plugged in to how their changes affect the build and other developers.
Then you can reap the bonuses by establishing higher compliance:
就像吃大象一样（一次咬一口）;-) 持续集成需要自动化构建。 从那开始。 自动化构建每件作品。 Ant 或 NAnt 是实现此目的的好方法。 让每个组件的构建成为一项 NAnt 任务。 然后，您的整个系统构建可以聚合这些单独的任务。
从那里，您可以添加用于部署、单元测试等的任务。如果您想使用 CI 技术，您可以将其连接到您的 NAnt 构建。
The same way you eat an elephant (one bite at a time) ;-) Continuous integration requires an automated build. Start with that. Automate the building of each piece. Ant or NAnt is a great way to do this. Have each component's construction be a NAnt task. Then your entire system build can aggregate those individual tasks.
From there, you can add tasks for deployment, for unit testing, etc. If you want to use a CI technology, you can wire it up to your NAnt build.
我首先会写下手动构建和测试所需的所有步骤。 之后，您至少有一个以旧方式进行操作的指南，并且将内容写下来使您有机会将其视为一个完整的过程。
然后寻找要编写脚本的部分。
理想情况下，您希望从代码提交触发构建和测试，并且仅重建和重新测试更改的部分，也许每晚或每周进行一次完整的构建和测试。 您将需要日志文件或数据库条目以及有关构建成功或失败的报告。
您需要搜索并评估预构建的产品和开源的构建您自己的套件。 您当然可以自己编写所有脚本和报告，但这需要一段时间，并且您最终可能会得到一个勉强足够好的报告系统，因为您的工作是对产品进行编码，而不是对构建系统进行编码。 :-)
I would start by first writing down all the steps it takes you to do the build and test manually. After that you at least have a guide for doing it the old way, and writing things down gives you the chance to look at it as a complete process.
Then look for parts to script.
Ideally you want to trigger a build and test from a code commit and only rebuild and retest the changed parts, with perhaps a full build and test nightly or weekly. You'll need log files or database entries and reports on the build success or lack of it.
You'll want to search out and evaluate pre-built products and open-source build-your-own kits. You can certainly write all the scripting and reporting yourself, but it will take a while and you'll probably end up with a just barely good enough reporting system since your job is coding the product, not coding the build system. :-)
我猜想迁移并不是真正的选择——半途而废的解决方案只会让情况变得更糟。
我的方法是找一位了解构建过程的创意工程师，让他坐下来说“解决这个问题”。 给他一两周的时间。
最终目标是一个使用单个 make 命令从头到尾运行的进程。
我还推荐一个自动化的“安装”过程，您只需进行检查并从网络共享运行批处理文件即可安装和构建所有工具。 如果您引入新的程序员，这将节省的总体时间是惊人的。 大多数项目需要一到三天的时间才能在新计算机上进行设置 - 而且总是“新”程序员不知道在自己的系统上进行安装时发生了什么......
I would guess that migrating isn't really an option--Half-ass solutions will only make it worse.
My approach would be to take one creative engineer who understands the build process, sit him down and say "Fix this". Give him a week or two.
The end goal would be a process that runs beginning to end with a single make command.
I also recommend an automated "Setup" procedure where you simply do a checkout and run a batch file from a network share to install and build all your tools. The amount of time this will save overall is staggering if you bring in new programmers. Most projects take one to three days to get set up on a new computer--and it's always the "new" programmer who doesn't know what's going on doing the installs on his own system...
简而言之：逐步
选择一个适用于各种项目的框架。
将组件一一添加到框架中。
如果您不熟悉该框架，请先解决几个更简单的组件，以减少搞砸的风险。
如果您确实了解该框架，请首先解决一些更困难和/或常见构建的组件，这样您的团队（和管理层）就会尽早体会到好处，并更多地支持这项工作。
请务必制定一个包含所有组件的计划，因为只有这样才能实现全部优势。
带上你的团队； 确保您一致认为这将是有价值的，否则随着组件的变化，人们不会维护它。
In short: Incrementally
Choose a framework that will work across the diverse range of projects.
One by one, add components to the framework.
If you are not familiar with the framework, tackle a couple of the easier components first, to reduce risk of screwing up.
If you do understand the framework, tackle some of the more difficult and/or commonly built components first, so your team (and management) will appreciate the benefits early, and support the effort more.
Be sure to have a plan to include all of your components, because that's when the full benefit will be realized.
Bring your team with you; make sure you have consensus that this is going to be valuable, or people won't maintain it as the components change.