版本管理

禅道简介： 禅道--项目管理软件，是国产的开源项目管理软件,专注研发项目管理,内置需求管理、任务管理、bug管理、缺陷管理、用例管理、计划发布等功能,实现了软件的完整生命周期管理。 禅道优势： 禅道版本 安装过程： 1.去官网下载linux系统开源版本： https://www.zentao.net/download.html 2.将压缩包上传到Linux 系统里 3.将安装包直接解压到/opt目录下 tar xvf ZenTaoPMS.9.0.1.zbox_64.tar.gz -C /opt 4.启动服务（进入开源版） cd /opt/zbox ./zbox start 5.配置发信邮箱 6.测试发信邮箱 总结： 1.项目管理工具不只有禅道，选择禅道是因为它有开源版，不收费，是国产的软件，支持中文，安装和操作都简单。 2.这里我安装的禅道版本是9.0，不是最新版本，若需要最新版本，可以去官网下载。 3.在开源版中，若一定要绑定公司邮箱，注意版本号，我安装了最新版本后，发现没有测试发信按钮，十分无奈。 来源： https://blog.51cto.com/13760351/2428467

目前在JAVA的世界中，maven已经成为事实上的构建标准，很多开源库的管理构建也是基于maven的，maven本身的学习曲线比较陡峭，遵循“约定优于配置”的理念，maven存在很多约定。本次我先描述下，关于版本的定义的选择，SNAPSHOT or RELEASE？ 版本之争 在maven的约定中，依赖的版本分为两类——SNAPSHOT和RELEASE。SNAPSHOT依赖泛指以-SNAPSHOT为结尾的版本号，例如1.0.1-SNAPSHOT。除此之外，所有非-SNAPSHOT结尾的版本号则都被认定为RELEASE版本，即正式版，虽然会有beta、rc之类说法，但是这些只是软件工程角度的测试版，对于maven而言，这些都是RELEASE版本。既然Maven提供了这两类版本号，那么他们之前的优劣势是什么？分别在什么场景下使用？ 解读SNAPSHOT 同一个SNAPSHOT版本的依赖可以多次发布（deploy）到仓库中，也就是说同一个SNAPSHOT版本的依赖可以在仓库中存在多份，每一份都是代码在某一个特定时间的快照，这也是SNAPSHOT的含义。 如上图，很好地表达了SNAPSHOT的细节，也阐述了一个SNAPSHOT很重要观点——SNAPSHOT不是一个特定的版本，而是一系列的版本的集合，其中HEAD总是指向最新的快照，对外界可见的一般也是最新版，这种给人的假象是新的覆盖了老的

问题： 在手机端的开发过程中，我们经常会遇见由于需求业务发生变化，导致后端的接口形式发生了变化，那么我们能不能从代码框架设计层面灵活的管理维护代码呢？ 目标：通过代码框架的设计，让开发人员能够更加好的去维护，管理每个代码的版本，让自己的项目也变得比较优美。 例如： 1：小程序的发布存在时差或者缓存，当前用户版本是1.0 你的服务端的版本可能是1.1 了，假设部分接口发生变化，会导致1.0的用户可能无法使用（如果是支付模块），让用户体验度下降 2：APP的版本更新，可能部分用户不及时更新版本，也会导致服务异常（虽然可以每次用户打开APP校验版本要求强制更新） 问题归类： 变化形式有如下2大类种，有几个小类别 接口形式发生变化 接口入参个数调整，由以前的1个，2个 变成了N个 接口请求发生发生变化，由GET换成POST 或者POST换成GET 代码层逻辑发生变化 查询的业务方法（Service层）发生 了变化 查询的数据库的Mapper 发生了变化 在开发的过程中，还有很多很多各种各样的问题，我只列举我遇见到的问题，如果有大神补充的，我也会及时更新上去。 解决思路： 针对目前列出2个大类，我自己想到了一部分自己初略的思路；（从外往内的整理思路来解决的） 问题1.接口形式发生变化时，参数个数发生了变化，这个时候，我们会使用重载的方式来通过参数的个数来控制接口不同的请求业务逻辑；

1.引言 随着项目不断的增大，尤其是一个在不断开发完善的项目，随着需求变化，数据库的schema也会跟着变化，数据库也需要不断的扩充，加表加字段，（每一次的增加称作一次DB的迁移migration）你是否还在用着最原始的方式， 用文件管理每次的SQL升级脚本，加了哪些字段，加了那些表，现在可以用数据库版本控制工具轻而易举搞定了。 flyway支持java API的操作方式，可以和spring 框架进行无缝连接，使其在系统启动的时候检查并升级数据库的版本（特别适合于java项目）。 2.flyway的特点 2.1使用它之前先要了解一些概念： 版本：对数据库的每一次变更可称为一个版本。 迁移：Flyway把数据库结构从一个版本更新到另一个版本叫做迁移。 可用的迁移：Flyway的文件系统识别出来的迁移版本。 已经应用的迁移：Flyway已经对数据库执行过的迁移。 2.2 .flyway最基本的几个命令。 Migrate ：应用所有的迁移到最新版本，它会在你的DB中新建个表 schema_version 来存放每次升级的版本信息。 Clean ：clean all objects Info ：打印所有的迁移的信息以及状态。 Validate ：迁移之前进行验证。 Baseline ：初始化 schema_version 表，并插入一条原始verion=1。 Repair

api:http://flywaydb.org/getstarted/firststeps/api.html 1. 引言 想到要管理数据库的版本，是在实际产品中遇到问题后想到的一种解决方案，当时各个环境的数据库乱作一团，没有任何一个人（开发、测试、维护人员）能够讲清楚当前环境下的数据库是哪个版本，与哪个版本的应用相匹配，如何升级到与新版本的应用相匹配。 想到管理数据库版本时，先是心底形成了一个初步的解决方案，大致是通过数据库中的某张表来记录数据库表结构的历次更新与对应版本，在每次数据库表结构调整时除了提供库表更新sql ，还必须提供更新记录与对应版本的sql，以帮助维护数据库版本信息，并在遇到问题时提供相关的排查依据。 后来据此思路在网络上搜索了一把，结果搜到Liquibase （另一款开源数据库版本管理工具）。在学习了解Liquibase 的时候，经高手介绍又了解到了Flyway 这个项目的存在。经过一番了解，最后我们选择了Flyway ，主要原因是Flyway 支持sql 脚本，而Liquibase 只支持XML 方式的数据库表结构定义，虽然在新的版本中号称在XML的数据库表结构定义方式中支持了sql 脚本。 虽然Flyway 的中文文档近乎为零，英文文档也凤毛麟角，但它却是我们最理想的数据库版本管理工具，它不但支持sql 脚本，还支持Java 代码直接操作数据库

下载 nvm-windows 最新下载地址： https://github.com/coreybutler/nvm-windows/releases 注意事项 选择nvm安装的路径中最好不要出现空格和中文 如果之前安装过node环境需要先卸载 安装完nvm之后输入 nvm list 如下： PS C:\Users\Administrator\Desktop\nodejs> nvm list No installations recognized. 安装node 运行 nvm install 8.11.4 64-bit PS C:\Users\Administrator\Desktop\nodejs> nvm install 8.11.4 64-bit Downloading node.js version 8.11.4 (64-bit)... Complete Creating D:\Node\nvm\temp Downloading npm version 5.6.0... Complete Installing npm v5.6.0... Installation complete. If you want to use this version, type nvm use 8.11.4 运行 nvm use 8.11.4 ,使用8.11.4版本的node环境 PS C:

随着社会的进步与技术的发展，人们对资源的高效利用有了更为迫切的需求。近年来，互联网、移动互联网的高速发展与成熟，大应用的微服务化也引起了企业的热情关注，而基于Kubernetes+Docker的容器云方案也随之进入了大众的视野。开普勒云是一个基于Kubernetes+Docker+Istio的微服务治理解决方案。 一、Microservices 1.1 解决大应用微服务化后的问题 现在各大企业都在谈论微服务，在微服务的大趋势之下技术圈里逢人必谈微服务，及微服务化后的各种解决方案。 1.2 当我们在讨论微服务的时候我们在讨论什么？ 使用微服务架构有很多充分的理由，但天下没有免费的午餐，微服务虽有诸多优势，同时也增加了复杂性。团队应该积极应对这种复杂性，前提是应用能够受益于微服务。 1.2.1 如何微服务化的问题 微服务要如何拆分 业务API规则 数据一致性保证 后期可扩展性考虑 当然这不是本文主要讨论的问题，我不讲微服务具体要如何拆分，每个企业每个应用的情况都不太一样，适合自己的方案就是最好的拆分方案。我们主要来解决微服务化后所带来的一些问题。 1.2.2 微服务化后带来的问题 环境一致性 如何对资源快速分配 如何快速度部署 怎么做基本监控 服务注册与发现 负载均衡如何做 以上都是大应用微服务化所需要解决的基础问题，如果还按照传统的方式使用虚拟机来实现，资源开支将会非常大