Dariusz Pasciak  2016年8月22日

        如果你正在使用Jenkins，你在创建项目时应该有一个叫“Execute Shell” 的步骤。

那个步骤的内容如下：

    bundle exec rspec

或者可以这样：

    bundle exec rake teaspoon

或者两者都有：

    bundle exec rake teaspoon

    bundle exec rspec

    bundle exec rake teaspoon

    bundle exec db:setup db:migrate

    bundle exec rspec

还有些是这样：

    bundle exec rake teaspoon

    bundle exec db:setup db:migrate

    bundle exec rspec

    curl -X POST -T failures.json https://my.data.com/failures

        或许它是以一行开始的，但是最终会增加到4行或更多行。

        将所有那些命令放到一个文件里（就是说，ci/build）以及从文本框执行那个文件，来代替用“Execute Shell”文本框来将所有跟你的构建有关的东西堆在一起。通过这个设置，你可以在源控制中检查那个脚本以及从中获得所有好处。

        首先，因为这个构建脚本是在源控制中的，所有使用它产生的历史对你来说都是可获得的。如果有需要，你可以研究你的项目和构建脚本是怎样形成的。然而，如果你的“构建脚本”只是在某个Jenkins配置页的盒子上的一串文本，那么你就不能从中得到任何历史。如果某人在构建脚本做了改进以及停止中断任何事件，只要它在源控制中你就可以很容易恢复到你之前的状态。

        其次，在源控制中记录你完整的构建过程意味着构建过程对于你存储的每个提交都是具体的。通过你的代码的所有更改，你也可以自由地修改构建脚本去反映那些更改。这里的意思就是说每个开发者都有自由去尝试不同的构建配置（例如优化，试验）而没有影响项目中任何一个人。

        尽管现在你的构建很简单，除了绑定exec rspec和mvn测试它也不会做其他事，那么继续将那些东西放到ci/build以及检查它吧。将来总会有一天你想在源控制中改变一点东西，事情将会变得更加简单。

Jenkins Pipelines

        更长远地考虑，如果我们将所有构建的细节都放到一个源控制的文件里那将会更加理想。如果你正在用经典的Jenkins作业那前面说的就真的不可能实现了，因为你仍然不得不人工地通过UI点击，创建作业，还有手动设置一系列东西。

        这可能十分枯燥和繁琐，那就是Pipeline插件产生的原因了。这个插件允许你在一个Jenkins文件里指定很多的构建配置，这也是源控制的。可能不允许把你当前的传统作业迁移到pipeline，但是可以十分肯定的是努力是值得的。试一试吧！

其他解决方案

        那里有大量的CI解决方案。我在这里用Jenkins作为一个例子，但是无论你选择哪一种方案，你都要确定它能够以某种方式让你的构建配置做源控制。

        持续集成快乐！

Dariusz Pasciak喜欢手工披萨和草饲牛肉汉堡，绿色的沙滩和雄伟的山脉，波兰民间音乐和优质软件。

【英文原文：https://8thlight.com/blog/dariusz-pasciak/2016/08/22/refactor-and-source-control-your-ci.html】

{测试窝原创译文，译者：梁仲兴}