开篇闲话

长期以来，笔者都在从事Android端上Apps的研发类工作，关注的重点，大多也都是在Android应用的功能实现、性能优化以及业务数据分析方面。
在加入现在这个团队之前，对于CI（Continuos Integration）持续集成的概念，笔者还停留在“开发机编译通过后，用jenkins在服务器上再执行一遍"的概念。而真正开始参与这项业务之后，才发现持续集成业务远远比简单的“编译-打包-发布”要来得复杂的多。

---

持续编译作为现代软件工程的附加概念之一，属于不折不扣舶来品。因此，也同样如《人月神话》中对软件工程的理解认知类似，即没有一个所谓包治百病的“银弹”能够解决实际工程中的一切问题——同样没有一种完美的CI手段，能够解决所有工程中所遇见的集成问题。

好的持续编译环境应该如精心培养的花卉植株一般，严格遵循者设计者对于工程项目的理解，将实际工程中所遇见的种种问题分拆解析，再按照合理的软件工程标准组装成最有工程效率的工具平台。

---

因此，笔者的初衷并非想像大部分常见的对Jenkins、Docker等工具的使用介绍，亦或是对软件工程理论的理论介绍的文章那样，对或是具体工具使用、或是理论概念进行一一剖析。在这里，笔者更想做一个自己时对于如何针对真实场景业务进行功能拆解，进而如何进行功能设计的思路记录。这也为自己将来，或者同行们面对如此问题的时候，提供一种有价值的解决想法。

而这个真实使用场景，目前定义为——互联网企业的智能硬件产品。

基本环境

笔者目前所效力的这个团队，是围绕着“自定义的Android操作系统跑在自定义硬件设备上，通过提供自定义端云服务以获取相关收益”来打造的产品。

因此首先可以简单的拆解一下关于集成编译这块的思路，即我们的产品发布形态是以工厂包->每日daily自动化集成->OTA正式发版的节奏进行的。
事实也正式如此，当笔者刚刚加入这个团队的时候，并没有一个真正意义上的“集成编译”环境，RD通过自己的开发机编译版本，刷入设备中交由QA进行测试，测试的过程中版本仍然继续迭代，如果发现了问题则在当前迭代的基础上继续开发。

“谢天谢地，他们至少是有一个专门提供版本的人，而不是每个人都能出版本。”

得益于当时软件版本的功能简单，以及硬件方面的型号单一，据说这么操作了大半年也没出什么乱子。

那么接下来，就是针对上述场景，需要提供一个最基本的软件工程场景。

• 与研发隔离的，专门编译环境，不需要人工参与编译。杜绝由于手工操作，或者引入了开发环境而造成的功能污染。
• 编译操作和发布都要可视化，不允许通过拷贝分发来传递版本。
• 软件版本号规范化。
• 软件管理引入SCRM概念。通过Sprint周期来管理需求和研发过程。

从我列出的TODO可以看出，一个架设在服务器端的Jenkins即可以满足上述的持续编译方面要求。

---

作为国内最知名的持续编译平台Jenkins，其基本的war包安装、启动、访问应该不需要我赘述。

安装完成的Jenkins通过shell脚本完成了对于源码的repo，编译。并且将编译的产物放置在了workspace空间中，供注册用户访问下载。

如此一来，有触发编译权限的用户，即可以通过Jenkins平台完成对Android Rom/App的编译工作，并且发布给下个环节的同学。

但问题也随之而来，新的Apps集成方案即将调整，用户开始变多Jenkins的权限不够清晰，产物仅通过workspace下载抢占了Jenkins的访问带宽……等等等等。

那么接下来的篇章里，我将一一记录那些出现了并且解决掉的问题。

“没解决的问题，我想我应该都把那些提出问题的人解决了。”