持续组件构建与版本管理

本文讲解基于Rainbond如何进行持续的组件开发

构建源管理

本文讲解Rainbond组件各类型构建源管理方式，包括更改代码地址、分支、账号密码，设置构建参数等功能

配置组件自动构建部署

本文讲解Rainbond组件与外部平台对接实现自动构建和部署的方式

通过应用复制快速搭建开发环境

应用开发过程中，同一个业务系统开发者可能需要重复多次的进行开发环境搭建。比如以下几类情况： 多个新功能在不同的分支进行同时迭代，那么不同的分支代码需要独立的部署； 团队中多个开发者进行开发，每个开发者都需要自己独立的一套开发环境； 开发环境应用开发完成，希望快速部署到测试环境或预发布环境； 生产环境灰度发布，希望快速部署指定组件使用指定的源代码版本； 遇到以上的情况，如果应用只有一个组件，或许从头开始创建并不复杂。那如果应用包括 5 个甚至更多组件的时候呢，创建过程将耗费大量时间且是在做重复的事情。这个时候基于已经部署好的应用直接进行复制则可有效解决效率问题。 前提条件 准备一个部署好的应用，可以包括使用源码、镜像创建的多个组件。 准备至少两个团队，验证跨团队应用复制。 组件对应的源码可以准备多个分支或者镜像可以准备多个 Tag，验证复制时便捷修改构建源版本。 操作流程 进入 应用视图/总览拓扑 页面，点击右上方 快速复制 按钮； 弹窗中上方区域显示复制的目标应用，默认是当前应用，可以根据需求选择不同的团队或应用，也可以直接在指定团队中创建新的应用。 弹窗中下方区域显示当前应用的所有组件信息及其构建源信息，默认选中所有组件进行复制，可根据需要选择部分组件。且可根据需要更改组件的构建源版本，比如代码分支或镜像的 Tag。 点击确定则开始进行复制，复制完成后自己构建并启动所有复制的组件，页面跳转到目标应用中。 了解原理 应用模型的关键性体现 Rainbond 中默认基于应用模型对各类型软件进行抽象管理，因此复制其实就是模型属性的复制，可以保障复制出来的组件与源组件属性保持一致。这再一次说明了一点，在 Rainbond 中部署组件的过程其实是在组装应用模型的过程，一旦部署完成即完成了业务模型的定义。 组件复制时依赖关系的处理 组件之间目前有两个属性具有关联性，包括组件依赖和存储依赖。复制组件时会存在两种情况，组件和依赖的组件双方一起被复制和只有依赖方被复制。若是双方都同时被复制，那么它们之间的依赖关系将保持，在新的组件双方之间进行建立，不管是否跨团队复制。若只有依赖方被复制，将会出现两种处理模式。复制的目标应用在当前团队下，则复制出的新组件依然依赖源依赖的组件，若复制的目标应用不在当前团队，那么依赖关系在复制时进行解除。 参考视频 应用复制与流量控制演示 常见问题 应用复制与发布到组件库后再安装的区别 应用复制是对当前应用模型属性的复制，不强调版本化，不进行应用模版化打包。使用起来更加灵活，适用于开发场景或同一个开发团队的测试、生产交付场景。发布到组件库的过程是对应用模型进行版本化保存的过程。基于组件库模版安装而来的应用其构建源信息是组件库模版，因此可以基于组件库模版进行持续的版本升级。这种模式适合应用开发方与使用方解耦合，应用进行多方、多环境交付场景。 应用复制与应用备份迁移的区别 应用复制是应用模型属性的复制，因此不会携带任何持久化数据和组件历史版本数据等。应用备份迁移是用于处于生产运行态的应用携带运行产生的所有数据进行迁移的过程。 更多使用场景 生产环境组件快速问题定位和解决 生产环境中某个组件出现问题但暂不能直接升级解决，我们可能需要修改部分代码快速验证是否有效。这时可以在应用中直接复制问题组件使用修改后的代码版本。然后修改网关策略，切换部分流量（比如以请求路径分离部分流量）到新组件上用以验证问题是否解决。这种方式既不影响生产组件又能快速解决问题。

高级环境变量配置

Rainbond关于环境变量的一些高级用法，适合于开发者参考，使应用可以有效的与平台产生互动。