Jenkins

http://updates.jenkins-ci.org/download/plugins/ 来源： oschina 链接： https://my.oschina.net/u/4405841/blog/4289063

技术只是基础 　　该系列的两篇文章《 .Net微服务实战之技术选型篇 》和《 .Net微服务实战之技术架构分层篇 》都是以技术角度出发描述微服务架构的实施。 　　如果技术选型篇叙述的是 工具 ，那么架构分层篇讲的就是 技巧 ，而本篇要讨论的就是 原则 。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。 　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。 什么才是优秀的架构设计？ 　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着 两句话 和 一个定律 ： 架构服务于业务，技术服务于架构 康威定律（简单理解成组织架构的设计等同于系统架构的设计） 　　 架构设计 其实就是一种 方案 的 取舍 ，在 有限 的 资源 里(包括但不限人力、时间)能让 团队 顺利的实施技术，同时满足 业务规模 的需要，我认为可以称之为优秀的架构设计，简单来说两个字 合适 架构核心要素 　　核心的主要5大： 性能、可用性、伸缩性、扩展性、安全性 。 　　而我们所讨论的微服务，选择了扩展性

技术只是基础 　　该系列的两篇文章《 .Net微服务实战之技术选型篇 》和《 .Net微服务实战之技术架构分层篇 》都是以技术角度出发描述微服务架构的实施。 　　如果技术选型篇叙述的是 工具 ，那么架构分层篇讲的就是 技巧 ，而本篇要讨论的就是 原则 。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。 　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。 什么才是优秀的架构设计？ 　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着 两句话 和 一个定律 ： 架构服务于业务，技术服务于架构 康威定律（简单理解成组织架构的设计等同于系统架构的设计） 　　 架构设计 其实就是一种 方案 的 取舍 ，在 有限 的 资源 里(包括但不限人力、时间)能让 团队 顺利的实施技术，同时满足 业务规模 的需要，我认为可以称之为优秀的架构设计，简单来说两个字 合适 架构核心要素 　　核心的主要5大： 性能、可用性、伸缩性、扩展性、安全性 。 　　而我们所讨论的微服务，选择了扩展性

【关键导读】 本文着重详解了接口测试解决方案的进阶之路，如何从典型的java+TestNG+Jenkins，围绕着提升接口测试ROI（减少投入成本，增加使用率）的目标，一步步结合业务应用实践，打造了一个高效的基于接口的团队协作平台GoAPI，让接口测试人人能做，人人能用，随处可用，以及如何做到1万+接口的业务的接口测试与管理。 一、历史的接口测试与管理 1.1 一个“活着”的接口 接口是应用开发中必然存在的产物，无论你是开发、测试还是运维人员，你都会与接口产生千丝万缕的联系。开发是接口的创造者，他们定义了接口，同时赋予了他们血肉之躯。测试是接口的健康守护者，无论在哪个阶段，都在默默的为他们找出伤害他们健康的“蛀虫”（To BUG）。听了我的YY，有没有觉得接口是有生命的，如果没有，那么可以看下下图 如此看来，接口是具有生命周期的，结合软件研发流程来看的话，在不同的阶段，不同角色都会围绕着接口做不同的事情。如下，一个“典型”的接口生命周期 接口生命周期中的每一个阶段都需要得到“细心的照料”，这就涉及到接口的测试与管理。接下来，将从历史的进程来看下，接口是如何被得到“照顾”的。 1.2 "历史”的接口管理与测试缩影 想到2014年，那是一个····的年头，我们的接口管理与测试是这么玩的，接口文档管理采用的是wiki，接口手工测试采用的是Postman/Jmeter

一、什么是PO模式 全称：page object model 简称：POM/PO PO模式最核心的思想是分层，实现松耦合！实现脚本重复使用，实现脚本易维护性！ 主要分三层： 1.基础层BasePage：封装一些最基础的selenium的原生的api方法，元素定位，框架跳转等。 2.PO层：元素定位、获得元素对象，页面动作 3.测试用例层：业务逻辑，数据驱动！ 三者的关系：PO层继承继承层，测试用例层调用PO层！ 二、什么是自动化测试框架 说到自动化框架，我相信很多人应该都听过这个词，但是不知其到底是个什么东西，为什么要用自动化框架。有很多人堆自动化框架都是懵懵懂懂，就跟谈恋爱一样，朦胧美！ 一个好的自动化测试框架是可以让不那么懂技术的人也可以写自动化测试脚本的， 一个好的自动化测试框架可以减少自动化测试中脚本管理和维护当中的人力物力和财力。 其实自动化框架的一个最大的意义在于可重用性。因为在框架里，你可以实现很多的通用功能来简化整个脚本的开发过程。并且生成美观的测试报告。 三、非PO模式和PO模式优缺点对比 自动化软件测试交流！！！群：642830685，领取最新软件测试资料大厂面试和Python自动化学习资料！一起学习交流 非PO模式 面向过程的线性脚本POM把页面元素定位和业务操作流程分开。实现松耦合。 复用性差UI元素的改变不需要修改业务逻辑代码

前面已经介绍过了 .Net Core 程序发布到 Docker 容器 的内容。但是每次通过 SSH 链接到服务器敲命令，运行脚本也是挺麻烦的一件事。程序员是最懒的，能让电脑解决的问题绝不手动解决，如果当我们push一次代码后自动build代码，自动跑单元测试，如果测试通过，自动发布程序，如果失败就发邮件通知管理员，这样的话该多美好。为了达成这个目标于是持续集成(CI)持续交付/部署(CD)就被发明出来了。CICD领域有个大名鼎鼎的工具：Jenkins，但是这次不使用它。如果你使用阿里云的话，阿里云已经提供了类似的功能，可以免去自己搭建Jenkins服务，以及Docker镜像私仓的过程，而且目前它们是免费的。 阿里云Codepipeline服务，是一套类似Jenkins的服务（其实我觉得它的核心引擎就是来自Jenkins）。 阿里云容器镜像服务，是一个镜像仓库，可以是公开的，也可以是私有的。 持续集成CI 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处主要有两个。 （1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 （2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前

技术只是基础 　　该系列的两篇文章《 .Net微服务实战之技术选型篇 》和《 .Net微服务实战之技术架构分层篇 》都是以技术角度出发描述微服务架构的实施。 　　如果技术选型篇叙述的是 工具 ，那么架构分层篇讲的就是 技巧 ，而本篇要讨论的就是 原则 。一直以来我会给身边向我探讨问题的人灌输一种理念，没有什么技术银弹，因为我们做的是软件工程，提供的是问题相应的解决方案，不同类型问题的解决方案是存在着本质上的差异。 　　继续提供之前的源码：https://github.com/SkyChenSky/Sikiro PS：该篇文章与.Net无关，其实主要是沿用前面两篇文章的命名，此外我认为DevOps不是简单的工具使用，应从软件工程角度进行出发。 什么才是优秀的架构设计？ 　　曾经有好几个同行问过我同一个问题：什么才是优秀的架构设计？我一直信奉着 两句话 和 一个定律 ： 架构服务于业务，技术服务于架构 康威定律（简单理解成组织架构的设计等同于系统架构的设计） 　　 架构设计 其实就是一种 方案 的 取舍 ，在 有限 的 资源 里(包括但不限人力、时间)能让 团队 顺利的实施技术，同时满足 业务规模 的需要，我认为可以称之为优秀的架构设计，简单来说两个字 合适 架构核心要素 　　核心的主要5大： 性能、可用性、伸缩性、扩展性、安全性 。 　　而我们所讨论的微服务，选择了扩展性

pipeline 语法实例三 按代码块优化脚本实例 /*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/* 1、源码分享如下： pipeline { agent any options { ansiColor('xterm') timestamps() timeout(10) } stages { stage(' Checkout ') { steps { git branch: '${branch_name}', credentialsId: 'GitLabAccess', url:'${repo_name}' } } stage(' Build ') { steps { echo 'build' sh "mvn -B -e -Dmaven.test.skip=true clean compile package" } } stage(' SonarQube ') { steps { echo 'SonarQube' sh "mvn sonar:sonar -Dsonar.projectKey=search-ci -Dsonar.host.url=http://110.139.139.133:29090

我希望我的经历能够帮助现在的软件测试人，特别是想往自动化方向发展的测试人。 我的职业生涯开始和大多数测试人一样，开始接触都是纯功能界面测试。那时候在一家电商公司做测试，做了有一段时间，熟悉产品的业务流程以及熟练测试工作流程规范之后，效率提高了，工作比较轻松，也得到了更好的机会去发展。 在后来的公司得到了领导的信任，待遇方面工资加上年终奖，加起来年薪能达到20W。由于当时公司规模和产品的局限性，导致自动化测试始终未能应用到公司项目中。外面的世界很大，自动化已经流行而且越来越普及，内心经过一番抉择后，我更想要突破自己的技术瓶颈，所以选择顶住了压力，跳槽到一家公司专职做自动化测试工作。通过不断的项目经历和机会，我将公司产品前后端的自动化测试全部落地实现。 那些自动化脚本真正成为了公司资产，每次上线回归带来的收益远超出我的预期。并且定时在公司的技术分享会展示效果，那种从0到1的成就感非常难忘。后面负责自动化测试团队工作，核心框架搭建。学习用到的技术栈：包括Python、Selenium、RF、Requests、Jenkins、以及见识到先进主流的Docker容器技术，持续集成 从手工到自动化测试/测试开发，给我带来的帮助不仅仅是20W到40W，待遇上面的提高，包括做自动化测试遇到的坑，解决问题的思路，以及技术瓶颈的突破，形成一套知识框架体系，得到一套有效落地的自动化测试方案。

当jenkins任务多的时候，为了减轻jenkins的负担，我们通常会增加节点来分担master的构建压力。 还有另外一种情况，就是节点也可以用来指定特定的环境，比如模拟环境等，然后通过节点配置或JOB中的标签指定到哪个节点上构建。 我的jenkins版本2.121.3，一台主机要作为jenkins的从节点: 从节点建议是干净的系统 从节点必须和主节点有一样的运行环境，比如java,maven,node等等 从节点不需要去启动jenkins，在你配置允许主节点免密码登录后，自己会同步一个slave.war包自己去启动,然后执行任务 另外，如果有版本控制，比如自建Gitlab，需要添加从节点的公钥Settings--SSH Keys(也可以是HTTP方式) jenkins--系统管理--管理节点--新建节点 节点名称 slave-213 选择固定节点 远程工作目录可以自定义，但必须有权限 启动方式，使用ssh方式，只要主可以免密码登录从就行啦 环境变量最好添加一下吧，也没几个，不然/usr/bin下要能找到可执行文件。 并发构建数：这个填写这台服务器可以同时构建几个任务，比如master,默认是2个，slave默认是1个，如果为0，表示该节点被移除，而且配置保留。 用法: 尽可能的使用这个节点 这是默认和常用的设置. 在这种模式下,Jenkins会尽可能的使用这个节点