在OmbuLabs，我们的专长之一是通过我们名为FastRuby.io的专业服务升级Ruby on Rails应用程序。在这篇文章中，我想和大家分享一下我作为一个经验不足的Rails开发者在做第一个Rails升级客户项目时的一些心得。
阅读Ruby on Rails教程真的没有让我为升级过程做好准备
在加入OmbuLabs之前，我主要是一个前端/UI开发者，致力于用HTML、CSS和jQuery构建网页，以及用WordPress进行一些简单的网络应用开发。虽然我通过元征学校的课程对软件工程的基础知识有了扎实的掌握，而且我还学习了一些Ruby on Rails的教程，为求职面试做准备，但我发现建立自己的应用程序并没有为我的升级过程做好准备。在我自己的应用程序中，我可以使用Rails生态系统中的最新工具从头开始。在工作中，我不得不涉足那些多年未曾升级的大型遗留应用程序。
幸运的是，我的队友已经写了大量关于FastRuby.io的升级理念和过程的文章以及一本电子书。我试图在客户项目开始前尽可能多地阅读文章。但在你经历过几次这个过程之前，这些知识纯粹是理论上的。
我天真地以为升级过程是直截了当的。FastRuby.io在任何升级发生之前的第一步被称为路线图过程。在这个过程中，我们与客户合作，以获得他们的代码、测试套件和构建流程，这样我们就可以通过以下方式检查应用程序。
- 首先，我们从 "双启动 "应用程序开始，这意味着我们使用FastRuby.io维护的名为next_rails的宝石，允许我们用下一版本的Rails运行现有的应用程序代码。我们这样做是为了确定应用程序是否运行成功，并记录下我们发现的错误信息和废弃警告。
- 其次，我们通过一些代码分析器运行代码，即skunk和codecov。我们这样做是为了了解当前整个应用程序的测试覆盖率，并检查代码的复杂性。我们使用审计来生成一份应用程序中使用的所有宝石的报告，以及一份关于每个宝石的安全漏洞的报告，其中包括为该漏洞发现的每个CVE的链接。
- 第三，我们查看Rails升级指南和目标升级版本的发行说明，以寻找与API删除、弃用或其他问题有关的重要信息。
这些发现将成为一份报告，其中包括升级的行动项目列表。从表面上看，这些行动项目中有许多在未经训练的人看来很简单，就是寻找和替换过时的方法或语法，或者升级一两个宝石。什么会出错呢？
拥有一个好的测试套件的重要性
好吧，我很快就知道了可能出错的地方。试图升级过时的代码，同时试图避免在你不熟悉的代码库的测试套件中引入额外的错误，就像建造一座纸牌房子--一个错误的举动，房子就会崩溃。我试图在提交拉动请求时注意测试套件，但很多时候我不明白测试套件的失败是由我修改的代码造成的，还是由于他们测试中的问题。我很快就明白了为什么OmbuLabs更倾向于承接那些测试覆盖率至少达到60%的项目。如果你没有一个自动化的方法来确定你的应用程序是否能正常工作，那么在升级之后，要想知道一切是否还能按照预期的方式工作，就会非常困难。
仔细检查你的工作
我在一些我认为 "容易 "的任务中遇到了一些问题。在我们的升级计划中，一项 "简单 "的任务是运行rake rails:update 任务（相当于早期Rails版本的rails app:update ）。这个任务的目标是运行rake rails:update ，为Rails 4.0创建一个更新的配置文件列表。一旦我知道哪些配置文件将在4.0中被更新，我就可以将它们与当前3.2的配置文件进行比较。然后，我就可以手动更新配置文件，使其与4.0兼容，而不需要删除rake rails:update 自动删除的所有自定义配置。不幸的是，这个过程并不像我希望的那样简单。在运行Rake任务后，我有了一个我知道可以更新的配置文件列表，但我不明白配置在做什么，为什么它在改变。
当我要为4.0更新配置文件时，我试着对要修改的内容采取保守的态度，这样我就不会以一个破碎的测试套件而告终。例如，我显然知道完全删除config/routes.rb 文件将是一个坏主意，尽管这正是app:update 任务所建议的。但是对于其他不太明显的变化，即使在查阅了配置Rails应用程序指南之后，我也不能完全确定我没有大幅度地改变什么。因此，当我创建PR并发现测试套件被破坏时，我并不感到太惊讶。我恢复了一些配置的变化，希望能解决这个问题，但是并没有。最后，和我一起做这个项目的一个高级工程师发现，我添加了一些不适合这个应用的资产配置。这有点尴尬，但也给我上了重要的一课：为什么要小心。
git的重要性
尽管我的git技能在我作为一个单独的开发者时表现良好，在我作为一个在团队中工作的开发者时也有90%的使用案例，但我很快发现我可以把我的git游戏升级一点。我在重新调整分支时很费劲，看着其他开发者挑拣提交的内容添加到新的PR中，我很紧张。至少有一两次，我慌忙打电话给和我一起工作的高级开发人员，因为我认为我搞砸了一个分支的重定位。每一次，他们都耐心地指导我完成这个过程，并在我们进行的过程中回答我的问题。我意识到，我不必害怕重新发布，到项目结束时，我已经可以自信地挑选提交的内容了。
我学到的最重要的东西
在这个项目中，我学到的最重要的东西是，问问题和依靠团队中比我更有经验的其他开发者是很重要的。在我过去的角色中，我是一个数字营销团队中唯一的网络开发人员。即使我想问问题，也没有人可以问。但我发现，在Rails的升级中，依靠我的团队的判断和过去的经验是很重要的，因为并不总是清楚解决方案应该是什么。
我从我的第一个客户项目中学到了很多东西--我对我们的升级过程为什么是这样的结构有了更深刻的认识，有了改进我自己工作的方法，以及与我的团队一起工作的重要性。我迫不及待地想把我学到的东西应用到我的下一个客户项目中。
