teamcity api如何通过casename找到build

每个build步骤中只做一件事情，然后把一系列的build步骤组织起来按顺序执行来完成build过程。

Build过程往往是比较复杂的，因此TeamCtiy通过build步骤的方式让您可以实现不同的应用场景。您可以在每个build步骤中只做一件事情，然后把一系列的build步骤组织起来按顺序执行来完成build过程。TeamCity会根据前一个build步骤的返回状态和当前的build状态来综合判断是否运行下一个build步骤。当满足下面条件时build步骤的状态被确定为失败：build步骤的执行过程返回了非零的退出代码并且该build的失败条件配置为起作用。其它情况则认为build步骤的状态为成功。我们可以在build步骤中指定不同的执行策略来告诉TeamCity究竟要不要执行下一个build步骤。

最近组内先后招了两名开发，作为他们的mentor，一方面我在观察他们的工作方式和编码习惯，另一方面也在对比思考自己的经历。自己有些感悟，觉得一名新人程序员，应该做好以下三点：

1.遇事追踪溯源，不要怕改已有的代码

2.编码在保证正确的前提下，要足够快

3.主动承接团队里他人不愿意做的或者没做的事

下面将逐一分析说明这三点。

1.遇事追踪溯源，不要怕改已有的代码

新人通常会从新加一个相似的功能或者修bug开始逐步熟悉原有的系统，这时无论原有的代码写的怎么样，都应仔细的思考每段相关代码的作用和对应的需求，努力做到追踪溯源，掌握它们的来龙去脉，这时再做task就会游刃有余，在做相似功能时，你知道哪些地方已经实现可以复用，哪些地方因为新加的代码应该做些重构；修bug时，你可以从根本原因出发，解决问题，而不是在出现问题的地方修修补补；更重要的是你不会打怵修改原有的代码而蹑手蹑脚。当然一旦发现要修改大段的原有代码或者设计，还是要主动和老员工先确认下思路是否可行，是否有遗漏的地方再开始。但不出意外，你会一下子就给别人留下一个好的第一印象，因为你没有在机械的完成任务，而是先做了深入思考。

写到这里不禁想起，自己刚工作时改了一个bug，当时的做法是在创建一个文件的代码之后3行再把这个文件删了，只加了一行代码就修好了，发给老员工review时还在窃喜自己只改一行代码就解决问题了，结果老员工一句话就把我问傻了，前面的那个文件为什么要创建呀？我当然不知道了，因为当时我想原有的代码我不熟悉就最好不动。于是，那一刻我得到了工作生涯第一个重要的建议，应该找到根本原因（rootcause）后再修改代码。这时你不仅可以做好手中的任务，还能进一步思考问题是不是代码设计不合理造成的，同时不会怕改已有的代码。

2.编码在保证正确的前提下，要足够快

新人在做第一个任务时都想留下好印象的，首先要做的就是一定要保证修改是正确的，这里不仅局限于正常情况下功能正确，还应考虑边界条件，错误处理情况等等，最后再提交代码时要最终确认一下单元测试过不过，提交代码后再注意下Jenkinsbulid过不过。这一切都是为了防止出现以下情况：

*一提交代码就breakbuild或unittest

*测试随便一点就有各种问题

*匆匆忙忙修了一个问题，一提交又有其他问题

别以为这些都些小事，它直接关乎别人对你的评价。不犯低级错误，建立起严谨的印象，是非常有助于你在新环境下脱颖而出的。

但仅仅这样是不够的，如何在保证正确的前提下，提高速度或者效率则是另外一个要点。试想一下，你持续超出别人的预期，并保质保量的完成了task，哪个领导和同事会不喜欢你呢？千万不要狭隘的觉得自己做的快了要多做事，何苦呀。也许短期内你多做了一些原本没分配给你的任务，但你在别人心中逐步建立起严谨高效的印象，从长期来看将给你带来更多的机遇（本人就是因此受益）。

3.主动承接团队里他人不愿意做或者没做的事

逆向思考下，人家为什么招你进来？相信绝大多数情况是事情多做不过来，缺人了。事情多了一定有老员工不愿意做，或者因为各种原因没做的事。作为新人，做了别人不愿意做的事可以缓和他人的压力；做了别人没做的事，将为团队增加产出，如果这件事还是一个技术难题，那不是正好可以让别人眼前一亮，证明自己的实力吗？

其实关于这一点，在做的时候要进一步深入思考。别人为什么不愿意做或者没做某些事？是因为缺乏相关知识而没有做？还是因为没有自动化每次手动操作既耗时又容易出错？是因为优先级不高？还是因为投入产出比不高？是因为代码结构不合理导致无法快速加上？还是因为需求不明确？是不是团队里的人因为思维定式错误估计了问题？是不是可以从其他的角度解决这个问题？要深入思考后，才能从根源入手，从而正确的解决问题。切记不要机械的完成任务，要努力让你的加入使团队变的更好。

自己在第二份工作的开始阶段，就发现团队还没有使用持续集成的工具在统一的环境下交付测试，测试还在通过访问开发机器上的网站验证功能，结果开发之间互相break情况经常发生，项目质量也无法保证。询问后才知道，大家也很希望改进现状，只是因为一些原因没法得到系统组的支持，组内也没人来搭建持续集成的环境。于是我利用一开始相对轻松的时间，使用teamcity搭建出持续集成的环境，一时间大家都纷纷叫好，加上自己又接连解决了项目中一些棘手同时没人做的问题，一下子就树立了可靠的形象和在团队里技术主力的地位，慢慢的即使是公司中其他组没合作的过的人也对我评价很高。我自己琢磨出的原因是团队里缺能干活的人，但更缺能让团队变好的人。

其实巧的是，如何使用teamcity搭建持续集成环境是我在第一份工作离职交接时主动做的最后一个task，因为当时有个小项目是我独立负责的，我想在交接时让项目更正规些，就主动提出这个想法，虽然在离职的前天晚上还在加班调试，当天上午还在和同事讨论一些细节，但就是这主动多做学会的技能成了我在第二份工作里出色开端的重要一环。

总结：

1.做事要知其然并知其所以然。

2.努力建立起严谨高效的形象。

3.成为让团队变的更好的人。

CI/CD工具包括GitLab CI、Jenkins、Bamboo Server、TeamCity、JFrog Pipelines等。比如JFrog Pipelines，就是下一代 DevOps 流水线自动化和编排解决方案，通过提供集中的命令和控制功能，来运用和提升流水线。流水线使云原生应用程序交付更简单，具有用于基于容器版本的高级功能，并支持旧式和现代应用程序，确保一致的体验。Pipelines 可广泛集成各种常见的 CI/CD 工具和其他 DevOps 技术，包括代码存储库、测试工具，以及部署过程。

---