ci

1.【错误经过：】 在 mysql数据库执行多表连接查询时： select * from A LEFT JOIN B ON A.user_id = b.user_id 出现错误： Illegal mix of collations (utf8_unicode_ci,IMPLICIT) and (utf8_general_ci,IMPLICIT) ​意思大概就是说 A表的编码格式和 B表的编码方式不一致，不能进行比较。 2.【解决办法：】 将 A表 和 B表 的 （ collations 或者 校对规则 ）的编码的方式统一为 utf8_general_ci 然后执行如下语句： ```mysql alter table 表名convert to character set utf8 collate utf8_general_ci ``` 注意 ！！！ 一般做了上面这一步还是不能解决问题，这是因为表里面的数据是之前插入进去的，编码方式自然也是之前的 utf8_unicode_ci 了，所以做数据比较的时候依然报错！！！要解决问题：还需要继续执行第二步，把表数据的编码规则也统一纠正过来 (另，注：utf8_general_ci和utf8_unicode_ci的区别，前者校对速度快，但准确度稍差；后者准确度高，但校对速度稍慢。） 来源： https://www.cnblogs.com

版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。 本文链接： https://blog.csdn.net/CrankZ/article/details/81545439 概述 敏捷开发和DevOps都是一种理念。他们的理念相似，都是为了更好更快的发布产品，但又不完全相同。 而CI/CD是实现这两者理念的一种方法。 敏捷开发 前言 传统方式开发前有一份详细的开发文档，程序员照着需求直接敲代码，产品做好了直接部署上线。中间不会有人打扰，需求也不会变。 但是目前的情况是，用户需求和市场都变化太快，就算你前期用户调研的再好，计划书写的再详细，也抵不住市场的变化，说不定产品做出来，用户就不需要了。 所以为了适应市场的发展，我们必须不断提高我们的开发效率，及时跟进用户需求，缩短开发周期。在这种情况下，就有人提出了敏捷开发。 传统开发 传统开发方式的拥护者和敏捷开发方式的拥护者看待软件开发的世界观是不同的。 在传统开发的眼里，软件开发过程是确定的、可测的，只要在一开始努力收集到需要的信息并制定好计划，然后忠实的执行计划就应该可以成功。如果不成功一定是你在一开始就没有做好，没收集到必要的信息，计划做的不好或者执行不到位。然后传统开发方式就试图引入更多的流程，文档，试图让每一步都做到万无一失。 敏捷开发 而在敏捷的眼里世界可不是这样的

1、右键选择你要更改的数据库，选择 属性（Properties） -> Options 2、Collation 选择 Chinese_PRC_90_CI_AS ps：collation的选项不一定，可以选择其他能用的哦~ 之后在要插入的中文数据前加上一个N，比如 insert into User(uid,username,password) values('kkkk',N'大傻瓜','123'); 注意， N与单引号之间无空格！ 以上。 如果还是无法解决，只能新建数据库，把collation设置为：chinese_PRC_CI_AS然后把数据重新导入到新数据库使用 来源： https://www.cnblogs.com/Sunshine-bing/p/11399038.html

在互联网时代，对于每一家公司，软件开发和发布的重要性不言而喻，目前已经形成一套标准的流程，最重要的组成部分就是持续集成（CI）及持续部署、交付（CD）。本文基于Jenkins+Docker+Git实现一套CI自动化发布流程。 一、发布流程设计 工作流程： 开发人员提交代码到Git版本仓库； Jenkins人工/定时触发项目构建； Jenkins拉取代码、代码编码、打包镜像、推送到镜像仓库； Jenkins在Docker主机创建容器并发布。 环境规划如下： | 角色 | IP | | :-------- | ::--------:| | Jenkins/Docker | 192.168.0.217 | | Docker | 192.168.0.218 | | Git/Registry | 192.168.0.219 | 操作系统：CentOS7.4 二、部署Git仓库 # yum install git -y 创建Git用户并设置密码 # useradd git # passwd git 创建仓库 # su - git # mkdir solo.git # cd solo.git # git --bare init 访问创建的这个仓库 # git clone git@192.168.0.212:/home/git/solo.git 三、准备Jenkins环境

DROP TABLE IF EXISTS `APIINFO`; CREATE TABLE `APIINFO` ( `ANF_ID` INT(4) NOT NULL AUTO_INCREMENT, `ANF_PID` INT(4) NULL DEFAULT NULL, `ANF_NAME` VARCHAR(100) CHARACTER SET UTF8MB4 COLLATE UTF8MB4_GENERAL_CI NULL DEFAULT NULL, `ANF_HOSTNAME` VARCHAR(200) CHARACTER SET UTF8MB4 COLLATE UTF8MB4_GENERAL_CI NULL DEFAULT NULL, `ANF_PATH` VARCHAR(100) CHARACTER SET UTF8MB4 COLLATE UTF8MB4_GENERAL_CI NULL DEFAULT NULL, `ANF_METHOD` INT(4) NOT NULL DEFAULT 1, `ANF_DELETED_FLAG` BIT(1) NULL DEFAULT B'0', `ANF_MEMO` VARCHAR(200) CHARACTER SET UTF8MB4 COLLATE UTF8MB4_GENERAL_CI NULL DEFAULT NULL, `ANF

一、Pipeline介绍 pipeline是一套jenkins官方提供的插件，它可以用来在jenkins中实现和集成连续交付 用户可以利用Pipeline的许多功能： 代码：pipeline在代码中实现，通常检查到源代码控制，使团队能够编辑，审查和迭代其交付管道。 持久：pipeline可以在Jenkins master的计划内和计划外重启中存活。 Pausable：在继续pipeline运行之前，pipeline可以选择停止并等待人工输入或批准。 多功能：pipeline支持复杂的实际CD要求，包括并行分叉/连接，循环和执行工作的能力。 可扩展：Pipeline插件支持其DSL的自定义扩展 和多个与其他插件集成的选项 二、k8s实现集成/部署/交付 三、创建一个gitlab的测试项目（网上找的简单代码测试） 1、测试代码 代码结构 [root@node2 test1]# tree . ├── pom.xml └── src └── main └── java └── hello ├── Greeter.java └── HelloWorld.java package hello; public class HelloWorld { public static void main(String[] args) { Greeter greeter = new Greeter();

1.1 持续集成、持续交付 介绍 　　 参考博客： https://www.cnblogs.com/cay83/p/8856231.html 　　1、传统交付 　　　　　　1. 传统软件的开发与交付的周期都很漫长，从需求的分析、系统的设计、编写测试用例、系统开发、单元测试、组装测试到交付调试。 　　　　　　2. 每一次交付、升级，都需要提供基础的硬件、软件的环境、软件的代码、软件的文档与手册。 　　　　　　3. 工程师都按照之前预演过好多遍的流程，对照着系统的部署手册，一步一步的组装硬件，安装软件，稍有差池，就要按照对应的应急预案进行回滚。 　　　　 　　2、技术工程师日常 与 痛点 　　　　　　1）立项，建代码库，申请资源，拉分支写代码，联调测试，发布到线上，设置监控点，质效分析和总结等等 　　　　　　2）这些活动存在于不同的平台，每天在不停的重复，需要不停的和各个团队沟通，不停的做研发平台和技术栈的切换 　　　　　　3）所以我们又回到持续交付的一个原则，如果有一件事让你感觉到痛苦，那么就尽早实现自动化。 　　　　　　4）梳理出规范化的玩法，采用自动化的高效手段，用技术去解决这些让我们感觉头疼的问题。 　　　　　　 　　3、CI 持续集成 与 CD持续交付 　　　　　　 持续集成 (Continuous Integration，CI)： 代码合并、构建、部署、测试都在一起

一、说明 1）需求： Kubernetes 上 部署 Jenkins-master，服务采用 Jenkins-slave 发布，发布完成后 Jenkins-slave 自动销毁。 2）环境： Rancher 2.2.7 （部署Rancher参考之前文章： 离线安装 Rancher2.2.4 HA 集群 ） Jenkins 2.176.2 二、安装 Jenkins 2.1 安装 Jenkins 在 Rancher 2 上部署 Jenkins-master 1）添加工作负载 名称：jenkins-master Docker镜像：jenkins/jenkins:lts 命名空间：jenkins 数据卷：jenkins-master-pvc，容器路径：/var/jenkins_home 2）添加负载均衡 名称：jenkins-master 命名空间：jenkins 自定义域名：jenkinscicd.xxxxxx.com 服务/工作负载：jenkins-master 容器端口：8080 3）添加域名解析 jenkinscicd.xxxxxx.com 172.16.5.84（ingress lb 地址） dig查看是否解析成功 dig jenkinscicd.xxxxxx.com 4）访问 1、浏览器访问连接：jenkinscicd.xxxxxx.com 2、在rancher上进入容器

curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-ci-multi-runner/script.rpm.sh | sudo bash sudo yum install gitlab-ci-multi-runner # 在root下执行 # 删除服务 gitlab-ci-multi-runner uninstall # 添加服务 gitlab-ci-multi-runner install --working-directory /home/jack --user jack # 重启服务 gitlab-ci-multi-runner restart # 查看状态 gitlab-ci-multi-runner status 输出：gitlab-runner: Service is running! # 查看是否生效 ps -ef | grep gitlab-runner 输出：root 17454 1 0 Mar23 ? 01:18:03 /usr/bin/gitlab-runner run --working-directory /home/jack --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog

简介 gitlab-ci全称是gitlab continuous integration的意思，也就是持续集成。中心思想是当每一次push到gitlab的时候，都会触发一次脚本执行，然后脚本的内容包括了测试，编译，部署等一系列自定义的内容。本文就是利用gitlab-ci的持续集成来实现自动部署。相比之前 webhook的自动部署 还是强大以及方便了许多。 原理 自动部署涉及了若干个角色，主要介绍如下 GitLab-CI 这个是一套配合GitLab使用的持续集成系统，是GitLab自带的，也就是你装GitLab的那台服务器上就带有的。无需多考虑。.gitlab-ci.yml的脚本解析就由它来负责。 GitLab-Runner 这个是脚本执行的承载者，.gitlab-ci.yml的script部分的运行就是由runner来负责的。GitLab-CI浏览过项目里的.gitlab-ci.yml文件之后，根据里面的规则，分配到各个Runner来运行相应的脚本script。这些脚本有的是测试项目用的，有的是部署用的。 .gitlab-ci.yml 这个是在git项目的根目录下的一个文件，记录了一系列的阶段和执行规则。GitLab-CI在push后会解析它，根据里面的内容调用runner来运行。 步骤 安装GitLab-CI 这个不用安装了，装好GitLab就自带了 安装GitLab