ci

swoole+Redis将实时数据的推送 一 实现功能 设计师订单如果设计师未抢单,超时(5分钟)设计订单时时给设计师派送, 设计师公众号中收到派单信息 设计发布者收到派单成功信息 环境 centos6.10 redis-4.0.2 swoole-src-4.4.12 php-7.1.5 MYsyql5.7 在centos6默认是gcc-4.7,安装swoole的时候需要升级到gcc-4.8 二 实现流程 1.开启swoole server端监听 2.开启swoole client连接执行定时执行 3.使用swoole task 异步执行推送逻辑 开始监听 服务端窗口 # php71 pushServer.php client连接执行开始任务 客户端窗口 # php71 pushClient.php start 默认start开启5个client tcp链接,每个链接开启一个1s定时器 开启后服务端窗口的变化 [root@111111 swoole_server]# php71 pushServer.php Client-1: 连接成功 reactor-7 Client-1 接受数据: data=start Client-1: 连接结束 Client-2: 连接成功 reactor-0 Client-2 接受数据: data=start Client-3: 连接成功 Client

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> utf8_general_ci 和 utf8_unicode_ci ，在性能方面是否存在差异？ #1楼 我想知道 utf8_general_ci 和 utf8_unicode_ci 之间的性能差异是什么，但是我没有在互联网上找到任何基准，因此我决定自己创建基准。 我创建了一个具有500,000行的非常简单的表： CREATE TABLE test( ID INT(11) DEFAULT NULL, Description VARCHAR(20) DEFAULT NULL ) ENGINE = INNODB CHARACTER SET utf8 COLLATE utf8_general_ci; 然后，我通过运行此存储过程将其填充为随机数据： CREATE PROCEDURE randomizer() BEGIN DECLARE i INT DEFAULT 0; DECLARE random CHAR(20) ; theloop: loop SET random = CONV(FLOOR(RAND() * 99999999999999), 20, 36); INSERT INTO test VALUES (i+1, random); SET i=i+1; IF i = 500000 THEN LEAVE

CI/CD【持续化集成/持续化交付】 docker搭建Gitlab环境 1.查询并拉取gitlab镜像 docker search gitlab docker pull gitlab/gitlab-ce:latest 2.启动容器 创建gitlab目录 启动之前，分别在gitlab目录下创建config、logs、data三个目录，分别用于挂载容器内不同文件 启动命令 docker run --detach \ --publish 8443:443 --publish 8090:80 --publish 2222:22 \ --name gitlab \ --restart always \ --volume /apps/Devops/gitlab/config:/etc/gitlab \ --volume /apps/Devops/gitlab/logs:/var/log/gitlab \ --volume /apps/Devops/gitlab/data:/var/opt/gitlab \ gitlab/gitlab-ce:latest 8090端口是页面访问端口 【注意】：gitlab初次启动比较慢，耐心等待后再访问页面！ 3.访问地址 http://192.168.92.130:8090 初始访问页面 登录使用： U：root P：F09..3 登录成功界面： 4.最后

bitnami VM https://bitnami.com/stack/gitlab/virtual-machine bitnami-gitlab-8.1.4-1-ubuntu-14.04.zip Version Size Checksum GitLab 8.1.4-1 (64-bit) 673 MB show GitLab8.1.4 GitLab Shell2.6.6 GitLab APIv3 Ruby2.1.7p400 Rails4.1.12 登录Gitlab服务器 在浏览器中输入虚拟机的IP地址 后弹出登录界面， 登录名为： user@example.com 密码：bitnami1 问题 不能启动SSH 用 /etc/init.d/ssh start命令不能启动SSH， 这会导致GIT客户端不能连接， PuTTY也不能远程登录。 D:\backup>git clone git@172.16.99.99:user/hello-world.git Cloning into 'hello-world'... ssh: connect to host 172.16.99.99 port 22: Connection refused fatal: Could not read from remote repository. 用以下方法解决： https://wiki.bitnami

持续集成/持续交付（CI/CD）在服务精细化、更新频繁的当下显得愈发重要。 本文将分享如何使用托管的GitLab.com解决方案来实现CI/CD，并将其与Kubernetes原生集成。且文中方法适合其他一切提供Kubernetes接口的CI/CD工具噢！ 持续集成/持续交付（CI/CD）的主题，在服务变得越来越细化、更新越来越频繁的当下，显得愈发重要。它让公司能够按照一种一致的、可重复操作的方式完全自动化地完成代码的搭建、测试和部署。 市场中有不少不同的CI/CD工具可供用户使用，它们中的很多将可以和Kubernetes进行原生集成。 本文将介绍如何使用托管的GitLab.com解决方案来实现CI/CD。不过本文中讨论到的Kubernetes集成是通用的，其他的CI/CD工具只要提供了Kubernetes接口，就同样可以按本文的方法、使用服务账号来与Kubernetes进行对接。 先决条件 用于部署工作负载的Rancher 2.0集群 登陆gitlab.com 设置GitLab.com 我们准备使用GitLab提供的一个模版，首先第一步先通过网址 https://gitlab.com/users/sign_in登陆gitlab.com 创建项目 将Kubernetes端点添加到你的项目中 上面所有的字段都需要填入内容，我会在下文介绍如何填写。 API URL API

1.前言 在上一篇讲述了如何在CentOS7中安装并使用代码质量管理平台SonarQube6.4，在上一篇中讲到了SonarQube支持多种方式来分析代码质量，其中有一种方式之一就是在持续集成工具中来自动完成代码质量分析，本篇就是继续上一篇来讲述如何安装并使用Jenkins。Jenkins的前身是Hudson，在写作本文时Jenkins的最新版本为2.84. 2.准备 软件准备： jenkins.war：Jenkins的部署文件，下载地址：http://mirrors.jenkins.io/war/2.84/jenkins.war Microsoft Build Tools 2015：无需安装VisualStudio，仅安装本软件即可使用MSBuild来编译Visual Studio创建的项目文件或解决方案文件，下载地址：https://www.microsoft.com/en-us/download/details.aspx?id=48159 3.安装 由于是直接下载的war文件，所以无需编译，只需将其放在Java的Web容器下即可。因在本系列中已经安装配置过Tomcat8.5，并且Tomcat的工作路径为：/usr/local/apache-tomcat-8.5.15/，因此jenkins.war放入/usr/local/apache-tomcat-8.5.15/文件夹

CICD（ C ontinuous I ntegration/ C ontinuous D eployment），持续集成持续部署的意思。完成CICD实践需要Kubernetes集群，Harbor，GitLab和Jenkins等软件配合完成，在前面几篇博客中，我已经搭建好了Kubernetes集群，并且在master节点（192.168.33.11,CentOS）上安装好了Harbor、GitLab和Jenkins，有需要可以参考下。 实践准备 CICD流程图 CICD的大致流程如下图所示： 开发者将最新代码提交到GitLab仓库； GitLab WebHook触发Jenkins构建流水线： 2.1 拉取最新代码； 2.2 Maven打包，打包过程中会先进行单元测试； 2.3 单元测试通过，构建Docker镜像； 2.4 将最新镜像推送到Harbor； 2.5 更新Kubernetes相关配置镜像版本。 Kubernetes感知到镜像更新，从Harbor拉取最新镜像，滚动升级； 开发者看到最新的代码效果。 项目准备 这里我们在Windows上使用IDEA、Spring Boot构建一个简单的Java Web项目，项目名为demo，项目pom如下所示： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

前端持续集成 先来讲下前端持续集成的流程吧，我画了一个简图。 我的目标是构建一个工程化的全自动环境，使得开发者在 不改变现有工作方式的前提下（无痛） 完成代码集成等一系列工作。影响的角色：开发，测试，产品经理，领导。 （图中实线代表需要手动进行，虚线代表自动执行） 1.1开发者首先提交代码到中央仓库，中央仓库触发钩子通知CI Server有代码提交。（ 开发者不需要为此做任何改变，和以前一样提交代码就可以 了） 1.2.收到通知后CI Server会自动执行一段脚本（checkout->build->lint->test）.完成之后会发邮件（调用Mail Service）通知开发者和代码维护者（比如tester等）构建信息 （全自动） 2.1开发人员给代码打tag，中央仓库触发钩子通知CD Server有tag生成。（ 开发者不需要为此做任何改变，和以前一样打tag就可以 了） 2.2收到通知后CD Server自动执行一段脚本（checkout->build->deploy） （全自动） 2.3项目上线后出现问题（报错）会邮件（调用Mail Service）通知开发者（图中也通知了维护者，视情况而定）报错的函数和上下文信息，方便开发及时发现问题并快速排查。 （全自动） 3.1开发者首先提交代码到中央仓库，中央仓库触发钩子通知package analyser（

你真的在做Cl吗 我猜你很有可能正在组织内使用持续集成。如果没有的话，你应该开始这么做，因为这个 关键实践允许我们更快速、更容易地修改代码。如果没有持续集成，向微服务架构进行转 型就会非常痛苦。即便如此，很多宣称自己在做CI的团队并没有真正在做。他们认为使 用了 ci工具就算是采用了 ci这个实践，事实上，只有工具是远远不够的。 我很喜欢jez Humble用来测试别人是否真正理解CI的三个问题。 •你是否每天签入代码到主线？ 你应该保证代码能够与已有代码进行集成。如果你的代码和其他人的代码没被频繁地放 在一起，那么将来的集成就会非常困难。即使你只使用生命周期很短的分支来管理这些 修改，也要尽可能频繁地把代码检入到单个主线分支中。 •你是否有一组测试来验证修改？ 如果没有测试，我们只能知道集成后没有语法错误，但无法知道系统的行为是否已经被 破坏。没有对代码行为进行验证的CI不是真正的CI。 •当构建失败后，团队是否把修复CI当作第一优先级的事情来做？ 绿色的构建意味着，我们的修改已经安全地和已有代码集成在了一起。红色的构建意味 着，最后一次修改很可能有问题，这时只能提交修复构建的代码。如果你允许别人在构 建失败时提交更多的修改，用于修复构建的时间就会大大增加。我见过在一个团队中构 建失败持续了好几天，最后花了很长时间才修复这个构建。 6.2把持续集成映射到微服务

Github 原生 CI/CD，初尝 Github Actions Intro Github 目前已经推出了自己的 CICD 服务 —— Github Actions，而且比微软的 Azure DevOps Pipelines 对开发者来说更友好，使用起来更好用。 Github Actions 核心概念 总体看下来感觉是从 Azure Pipelines 迁移过来的东西，有许多概念和 Azure Pipelines 是类似的，如果你之前用过 azure pipelines，应该很容易上手 Runner 用来跑 cicd build 的服务器 Github Hosted Runner Github 官方提供的 Runner Self-Hosted Runner 用自己的服务器作为 Runner Workflow 定义 CI/CD 的流程，需要执行哪些操作，需要做什么 Workflow 定义 workflow 的配置文件，通常放在项目根目录下的 .github/workflows 文件夹下 Workflow Run 每一次 CI/CD build Event 触发 ci/cd build 的事件，如 push/issue/pr Job 由一系列 Step 组成，Job 可以并行执行也可以串行执行，每一个 Job 都是一个新的环境 Step 对应 Job 执行的每一个步骤 Action