ci

写在最前的总结：Jenkins其实就是一个工具，这个工具的作用就是调用各种其他的工具来达成你的目的。比如你要获取Subversion上最新的源代码，Jenkins会去调用SVNKIT(插件的核心Jar的名称)。然后你需要编译源代码(假设是用maven编译)，Jenkins会去调用maven的插件。最后你可能需要发布程序到服务器上(假设是使用的Tomcat提供服务)，你可以通过Tomcat自己的API发布程序(有个插件就是通过这个功能实现的发布)，你也可以通过ssh通道自己写shell脚本去实现。总之，Jenkins就是一箱工具，在它能力范围内你想干什么都可以。 Q:Jenkins是什么？ A:百度一下你就知道！ Q:Jenkins有哪些版本？ A:这个版本太多了，具体去看官网吧！www.jenkins-ci.org Q:应该选择哪个版本的Jenkins？ A:如果你是公司正式使用推荐长期支持版(LTS)，原因：稳定。如果你是学习，随便哪个版本都可以。 Q:JDK应该安装哪个版本的？ A:推荐安装JDK7，原因：某些插件必须要求JDK7的支持。比如： Monitoring 插件 Q:Tomcat应该用哪个版本的？ A: Tomcat6或者7都可以。如果你要用Tomcat5.5的版本，我劝你趁早扔掉。不然一堆稀奇古怪的错误，看得你头晕。 Q: 可以直接用命令启动么？ A: 可以。命令

背景 在目前快节奏生活已经成为社会风潮的大背景下，越来越多的互联网公司为了其应用产品能更快的掌控风向脉搏，抢占市场红利，需要更快速的应用产品开发上线，在市场的反馈下，不断的迭代新功能。在此需求下，持续集成，持续部署，持续交付被越来愈多公司所推崇，DevOPS文化的兴起，一方面是实践打破运维与研发的堡垒之墙，另一方面也是敏捷开发过程中的必要产物。 提高软件开发效能，快速迭代、快速试错，以及根据自己开发团队特点，使用怎样的技术手段，才能是软件开发效能最高，更为快速敏捷，以及怎样才能满足产品能在最短周期、高质量的交付业务的诉求？ 本专栏在此背景下为大家提供Gitlab CI持续集成方案，通过一些列实战，让各位能够能直观清晰的理解这种模式，本专栏为抛砖引玉，各位结合，读者可以结合自己实际的生产环境来考虑是否引入此中模式，优化交付流程，释放研发最能大潜能，与此同时，读者可以在本专栏体验端到端的 CICD 的如丝般顺滑的CI体验，并且无论运维人员还是开发人员都能够在本专栏更系统宏观的了解和学习Gitlab CI的流程及具体操作方式。 一、 Gitlab 提到Gitlab CI，大家可能都会想到Gitlab，其作为目前最火的开业git托管服务端，相较于Github，各企业可以进行私有化部署，服务器自己维护，项目数据更加安全更可控，网络也更快及更安全。 Gitlab 为用户提供友好的web界面

说明 本文简单介绍下 Gitlab CI ，包括Gitlab Runner，Gitlab CI中的相关概念以及.gitlab-ci.yml的常用配置。 部署GitLab 请参考 Docker-compose部署gitlab中文版 什么是 GitLab CI GitLab CI 是GitLab内置的进行持续集成的工具，只需要在仓库根目录下创建 .gitlab-ci.yml 文件，并配置 GitLab Runner ；每次提交的时候，gitlab将自动识别到 .gitlab-ci.yml 文件，并且使用Gitlab Runner执行该脚本。 Gitlab Runner GitLab-Runner就是一个用来执行.gitlab-ci.yml 脚本的工具。可以理解成，Runner就像认真工作的工人，GitLab-CI就是管理工人的中心，所有工人都要在GitLab-CI里面注册，并且表明自己是为哪个项目服务。当相应的项目发生变化时，GitLab-CI就会通知相应的工人执行对应的脚本。 Runner类型 GitLab-Runner可以分类两种类型： Shared Runner（共享型） 和 Specific Runner（指定型） 。 （1）Shared Runner：所有工程都能够用的，且只有系统管理员能够创建。 （2）Specific Runner：只有特定的项目可以使用。

CI: 持续集成（CONTINUOUS INTEGRATION） 在持续集成环境中，开发人员将会频繁的提交代码到主干。这些新提交在最终合并到主线之前，都需要通过编译和自动化测试流进行验证。这样做是基于之前持续集成过程中很重视自动化测试验证结果，以保障所有的提交在合并主线之后的质量问题，对可能出现的一些问题进行预警。 持续集成（CI）是一种软件开发实践，开发人员经常在其中进行代码更改并将其添加到中央存储库中，然后再运行自动化测试。CI是软件发布过程的集成阶段，它取决于自动化和持续集成。主要目标是发现错误并迅速解决问题，以提高软件质量并缩短产品上市时间。 在持续集成中，开发人员一天要专注于较小的提交。开发人员将代码从存储库中拉出，然后再将其推送到构建服务器，构建服务器将在其中运行各种测试以验证代码提交。 CD:(1) 持续交付（CONTINUOUS DELIVERY） 持续交付就是讲我们的应用发布出去的过程。这个过程可以确保我们尽可能快的实现交付。这就意味着除了自动化测试，我们还需要有自动化的发布流，以及通过一个按键就可以随时随地实现应用的部署上线。 通过持续交付，您可以决定每天，每周，每两周发布一次，这完全可以根据自己的业务进行设置。 但是，如果您真的希望体验持续交付的优势，就需要先进行小批量发布，尽快部署到生产线，以便在出现问题时方便进行故障排除。 持续交付是一种软件开发实践

CI/CD with Data: 通过AWS Developer Tools、 Kubernetes和Portworx来实现软件交付Pipeline的数据迁移能力 数据是应用最重要的部分。容器技术让应用打包和部署变得更快更容易。对于软件的可靠交付来说，测试环节变得更加重要。由于所有的应用都包含数据，开发团队需要办法来可靠的控制、迁移、和测试真实的应用数据。 对于一些团队来说，通过CI/CD pipeline来移动应用数据，为了保持合规性和兼容其他一些问题，一直是通过手动方式来完成的，无法有效扩展。通常只能适用于一小部分应用，而且无法在不同环境中迁移。目标应该是运行和测试有状态容器，如同无状态容器一样简单（有状态容器 – 例如数据库或者消息总线，其中运行是被追踪的；无状态容器 – 例如网页前端） 为什么测试场景中“状态-State”十分重要？一个原因是许多bug只会在真实数据的环境下才会产生。例如，你需要测试一个数据库的schema的升级，而一个小的数据集并不能完全代表包含复杂商业逻辑的关键应用。如果你需要进行端到端的完整测试，我们需要能够容易的管理我们的数据和State。 在本篇文章中，我们定义CI/CD Pipeline的参考架构，从而能够达到应用间的自动数据迁移。我们也展示如何配置CI/CD pipeline的步骤。 有状态Pipelines: 需要可迁移的卷 作为持续集成

Preface Atcoder的题都好劲啊，都是我做不动的 计数 与 构造 就当锻炼自己的思维能力了（基本都是bzt教的） A - XOR Circle bzt说这题数据太水了只要判一下所有数异或值是否为 \(0\) 就能过，但我们要考虑正解（数据太弱我也不知道到底对不对） 首先我们发现放数的时候必然会出现 \(a_1\to a_1\operatorname{xor} a_2\to a_2\to a_1\) 的情况，即三个数一组的循环 那么我们可以得到一个普遍的结论：只有三种数且每种 数字个数相同 然后你直接提交就会WA掉，原因是忽略了 \(0\) 的情况，因此我们要加上下面两个特判： 全为 \(0\) 时显然合法 \(3|n\) 且只有两种数（一种是 \(0\) ）， \(0\) 的个数为 \(\frac{n}{3}\) ，非零的那个数个数为 \(\frac{2n}{3}\) 。假设非零数为 \(x\) ，显然可以放置成 \(x\to 0\to x\to x\to 0\to x\to \cdots x\to 0\to x\) #include<cstdio> #include<cctype> #include<map> #include<utility> #define RI register int #define CI const int& #define Tp

某厂面试归来，发现自己落伍了！>>> 先看几行代码： <!-- lang: php --> class A { private $b; function __construct($a){ $this->b = $a; } function func1(){ var_dump($this->b); } function func2(){ $this->funcb(); } } class B extends A { function funcb(){ var_dump("b"); } } $a = new B('a'); $a->func1(); $a->func2(); 这几行代码是没有错误的，在父类中调用子类的方法，子类实例化之后可以正常工作。 CI的DB部分正是使用了这种方式来封装数据库操作。 CI的DB函数的写法正是先加载 CI_DB_driver 这个基类，然后检查active record是否开启，如果开启则 <!-- lang: php --> class CI_DB_active_record extends CI_DB_driver 然后 <!-- lang: php --> class CI_DB extends CI_DB_active_record 否则 <!-- lang: php --> class CI_DB extends CI_DB_driver

某厂面试归来，发现自己落伍了！>>> 在Tp中select是查询的，相当于mysql语句中的select * from `tablename`; 而在ci中相当于选择需要查询的字段，真真执行的是get来执行查询。 where_in()等等都是构成sql语句的条件，并不执行， 如果你是在模型中用直接return $this->db->get()那么在控制器中接收到的只是一个对象，result_rows是没有数据的。 还有值得注意的一点就是如果是在控制器加载模型，那么模型的名和控制的名不能重复，不然会加载失败：报寻找不到CI_Model类，虽然你明明extends CI_Model类。 来源： oschina 链接： https://my.oschina.net/u/2612404/blog/685888

CodeForces - 1324 D. Pair of Topics 原题地址： http://codeforces.com/contest/1324/problem/D 基本题意： 给你一个数组，找符合（i < j）ai + aj > bi + bj 的序列对的数量。 基本思路： 本质上我们设 ci = ai - bi 那么原式可以换为 ci + cj > 0，所以我们可以有几个思路： pbds黑科技解法，我们转换为 cj > -ci 直接上红黑树每次插入 -ci 暴力往前找rank； # include <bits/stdc++.h> # include <bits/extc++.h> using namespace std ; using namespace __gnu_pbds ; # define IO std::ios::sync_with_stdio(false) # define ll long long # define INF 0x3f3f3f3f typedef tree < pair < int , int > , null_type , less < > , rb_tree_tag , tree_order_statistics_node_update > rbtree ; const int maxn = 2e5 + 10 ; int n , a [

对于一个前端应用，或者说是一个 Node 应用，在 CICD pipeline 中，无论是构建，测试，部署，其中必不可少的环节就是依赖安装: npm i 。 npm i 不仅是必不可少的环节，而且很可能也是耗时最长的一个环节。 打蛇打七寸，优化应该从瓶颈处开始，如果能从依赖安装下手，将能极大地缩短部署时间，提高产品交付效率，改善 DevOps 流程，从而促进敏捷开发。 CI 环境中的优化不同于本地开发环境，其中最大的不同在于: 在本地环境中安装依赖是有状态的，如 node_modules ， ~/.npmrc ， ~/.npm 一系列硬盘目录及文件，无不构成状态。而在生产环境中，往往结合 CICD 工具，每次分配的 Runner 不一定是一台服务器(容器)，往往被视为无状态，因而无法有效利用缓存而导致 CI 中部署用时过长。 但也正因为 CICD Runner 的无状态化，这意味着你只要参考构建脚本，如 .gitlab-ci.yaml ， .travis.yaml 或者 .github/workflows/deploy.yaml ，就可以从零把项目跑起来，而避免过多在熟悉新项目时求助他人。 不同的部署方式，不同的持续集成工具有不同的实践方法，但优化的原理大同小异。 如果嫌文章太长，直接直接拉到最下方看总结 只安装有必要的库 npm install