devops

DevOps是当前软件行业最热门的话题，无论是互联行业，还是传统行业，大家都在拥抱DevOps，享受引入DevOps后带来的团队效能提升。但是也有不少的团队对DevOps的理解还存在误区，导致在实践过程中困难重重，甚至最终失败，总结失败的原因不外乎以下几点： 认为引入DevOps就是引入一套工具集合并在团队（企业）内部将工具集用起来。 DevOps的实践本身也是一项系统化的工程，就目前的行业现状来说，想要直接复制成功的经验难度较高。 有一些团队（企业）把通过DevOps能力成熟度认证作为DevOps的实践目标，只是针对DevOps能力成熟度进行DevOps建设，却忽略了当前自身的团队（企业）也要为之做出一些变革。 DevOps涉及的环节众多，许多团队（企业）在实践DevOps时偏向敏捷开发（需求管理）、持续集成（流水线）等环节，而忽略了测试环节。 DevOps的实践落地即不是一个成功案例经验的复制，也不是一套工具的引入与使用，更不是单纯的获取能力成熟度认证，它本身是一项体系化的、持续化的工程，需要在实践的过程中不断的针对DevOps的各个环节进行优化。 从测试的角度来说，如果想要拥抱DevOps，则必须要向敏捷测试转型，本文将从测试环节出发，探讨测试在DevOps中的位置以及如何在团队中推动敏捷测试落地。 瀑布与敏捷 回顾整个计算机发展史，提升软件开发效率始终是无法回避的话题

导读 作为一个非常喜欢GitHub的程序员，我在日常使用中发现了这4个技巧，可以提高我使用GitHub的效率。这篇文章介绍并演示了这4个技巧，我希望它们也能帮助你更有效地使用GitHub。 技巧1：用文件查找器快速、轻松地搜索仓库中的文件 GitHub提供使用Git进行软件开发和版本控制的托管，有数千个存储库、项目和文件。因此，如何高效地在GitHub上搜索文件是非常重要的。第一个技巧是使用GitHub在仓库中提供的快捷方式搜索仓库中的文件。 如上图所示，在运行时的仓库页面，按键盘上的 t 键，那么GitHub就会激活文件查找器。然后你只需要输入目标文件名，比如ServiceProvider.cs 文件，文件查找器就会显示你想要的文件。 技巧2：使用搜索限定词搜索你想要的目标 现在，假设你不知道目标文件位于哪个仓库中，或者你想在组织中查找某个用户。然后，你可以使用搜索限定词在GitHub的任何页面上搜索所需的目标。 如你在上面看到的，我们在Marketplace页面上，并希望在dotnet组织中搜索ConfigurationBuilder.cs文件。然后，你只需要输入搜索限定词即可表明此目的。 org:dotnet filename:ConfigurationBuilder.cs GitHub就会显示你想要的文件。 技巧3：在Github个人资料页面上启用自述文件 是的

微服务架构 概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。 定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。 本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。 基于微服务架构的设计： 目的：有效的拆分应用，实现敏捷开发和部署 微服务的具体特征 官方的定义： 1、一些列的独立的服务共同组成系统 2、单独部署，跑在自己的进程中 3、每个服务为独立的业务开发 4、分布式管理 5、非常强调隔离性 大概的标准： 1、分布式服务组成的系统 2、按照业务，而不是技术来划分组织 3、做有生命的产品而不是项目 4、强服务个体和弱通信（ Smart endpoints and dumb pipes ） 5、自动化运维（ DevOps ） 6、高度容错性 7、快速演化和迭代 为了更好地理解微服务和设计微服务架构，列出几个比较经典的设计图辅助理解： 来源： oschina 链接： https://my.oschina.net/u/4273871/blog/4437241

2020年注定是不平凡的一年，一场突如其来的新型冠状病毒在全球肆虐，部分企业还在复工的路上稳阵脚、备粮草、找契机，“静候”复工的号令，而阿里的同学早已吹响了“无接触，云办公”的号角，全面启动远程研发协同办公的硬核“神器”——“移动研发平台EMAS”。 “云办公”让企业向移动化转型升级迎来一场实战考验，对于多数传统企业而言，需求沟通、研发效率、测试保障、发布质量、运维稳定、运营分析等各个环节都充满了挑战。阿里的同学亮出“云办公”高效率、协同化、流程化的“杀手锏”，利用移动研发平台EMAS助力远程研发协同，仅用5天时间便完成手机淘宝“三八国际女王节”新版本全链路发布。“居家办公”也能如此高效？经过复盘与梳理，深度揭秘手机淘宝新版本开发流程，探索阿里工程师在这5天“云办公”中的速度与激情。 2月25日：远程研发，只需1天 许多业内小伙伴开启远程研发办公后惊呼：一线上，全乱了。而阿里工程师仅用1天的实践就证明了移动研发平台EMAS的强大功能和硬核技术。 视频晨会，产品经理“淘小二”完成需求部署，客户端开发“叮叮”同学便迅速开启手机淘宝“三八国际女王节”版本视频直播模块功能开发。在移动研发平台EMAS上新建项目、添加模块、输入代码、构建手机淘宝客户端，最后扫码安装、自测验证，整个流程规范而高效。与此同时，系统配置的自动化测试流水线也开始默默运行起来。

根据 2017 年的 DevOps 发展报告，高效能组织和低效能组织在软件交付的效率上有数量级上的差异。技术组织的软件交付能力是一种综合能力，涉及众多环节，其中发布是尤为重要的环节。 作为技术人员，大家可能听说过“滚动发布”和“蓝绿发布”等术语，但是很多人并不清楚这些术语背后的原理。本文试图总结当前主流的发布策略，每个的优劣，适用性，让开发人员特别是架构师对现代发布技术有一个更为清晰全面的认识，让大家能够根据自己的企业上下文，对发布策略做出正确的选型和实践。 一、单服务器组发布 先解释下单服务器组的概念，早先我们机器资源比较紧张，不像现在云计算和虚拟化（包括容器技术）这么发达，所以应用机器基本是预先静态分配好的（一般由运维负责分配），原来应用 A 住在这 n 台机器上，那么下次升级发布的应用 A 也住在这 n 台机器上，所以称为单服务器组发布方式。 1.1 蛮力发布 如下图所示，这种发布方式比较简单粗暴，有点像我们传统的软件升级方式，主要靠手工完成，先将老版本 V1 全部下掉，再将新版本发到机器上去。这种方式会引入服务中断（停机），在开发测试环境是可行的，但对于生产环境发布，其会直接影响用户的使用体验，这种方式一般是不建议的。 发布前 发布后 优势和适用场合 优势： 简单成本低 不足： 服务中断用户受影响，出了问题回退也慢 适用场合： 开发测试环境 非关键应用（用户影响面小）

今年以来，受到疫情“黑天鹅”事件的影响，人们的工作方式和生活消费习惯已经悄然发生改变，在线教育、在线医疗、在线购物等新需求快速的增加，一方面展示出了数字经济所带来的巨大优势，但另一方面也对企业数字化转型提出了前所未有的挑战。 例如，疫情让很多线下场景暂时缺席，实体流量退去，那么通过数字化营销、在线服务、电商服务等，打通线上线下，形成多接触点的方式，就能将疫情带来的损失降到最低，可以说在线化和移动化已成为未来可持续最强的交互渠道。 换句话说，经济和用户性形态的巨变正在倒逼企业数字化转型加速，企业数字化转型正从此前的“转不转”变化为“转什么”以及“怎么转”的新课题。其中，移动化应用作为企业通向移动互联网的“入口”，其对企业加速数字化转型的重要性不言而喻。 从这个角度来看，在后疫情时代，随着“新基建”的提速，以及数字经济进一步的蓬勃发展，显然进一步放大了企业数字化转型的迫切性。所以，重新审视在不确定性环境下的应变能力，构筑企业一体化的移动服务平台，已经不再是一道选择题，而是必须给出的答案。 后疫情时代数字化转型 在今年疫情期间，无论是从科技防疫、工作学习还是到日常生活，我们从未像现在这样依赖移动互联网。近期发布的第45次《中国互联网络发展状况统计报告》就显示，今年年初受疫情影响，大部分网络应用的用户规模都呈现出较大幅度增长。 以在线教育为例，2020年初，全国大中小学校推迟开学，2

在 KubeSphere 3.0 里我们完成了很多对企业用户重要的特性，本文将从基础设置、运维、应用开发与管理、生态及混合云场景等多个层面给大家带来分享，也欢迎大家使用并反馈。 数字化转型的核心是快速向市场交付产品、服务和价值，一套能够承载企业核心应用敏捷开发和灵活运营的基础架构至关重要。混合云使企业在基础架构的敏捷性和可靠性、经济性和安全性之间得到平衡，成为越来越多企业数字化转型基础设施的选择。 2020 Flexera™STATE OF THE CLOUD REPORT 随着数字化竞争加剧，企业需要将更多的精力从基础设施中解放出来，投放在核心应用上。同时，云原生的到来促使混合云容器化——基于容器标准化封装解除应用运行环境与混合云异构基础设施的耦合，使企业更易于实现敏捷开发和持续交付。然而，在企业生产中，这些远远不够，例如: 如何将应用跨平台进行统一分发和运维管理？ 在容器混合云中部署应用，如何实现多区高可用？ 运维如何简化以满足 DevOps 下的应用快速交付？ 本次 KubeSphere 3.0 重磅发布，以上问题迎刃而解，为企业带来可落地的容器混合云解决方案，助力企业在数字化转型中快人一步。 KubeSphere 是基于 Kubernetes 构建的多租户、多集群、企业级开源容器平台，具有强大且完善的网络与存储能力，并通过极简的人机交互提供完善的多集群管理、CI/ CD

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

基于NAT网络配置centos8 默认网卡配置文件：/etc/sysconfig/network-scripts/ifcfg-ens33 [root@A8 ~]#vim /etc/sysconfig/network-scripts/ifcfg-ens33 BOOTPROTO=static NAME=eth0 DEVICE=eth0 ONBOOT=yes IPADDR=10.0.0.8 GATEWAY=10.0.0.2 PREFIX=24 DNS1=114.114.114.114 DNS2=8.8.8.8 配置完网卡文件之后我们就可以使用nmcli命令重启网卡使其生效 [root@A8 ~]#nmcli c load /etc/sysconfig/network-scripts/ifcfg-ens33 nmcli命令解释 nacli使用： 用法：nmcli [选项] OBJECT 选项： -o[verview] 概览模式（隐藏默认值） -t[erse] 简洁输出 -p[retty] 整齐输出 -m[ode] tabular|multiline 输出模式 -c[olors] auto|yes|no 是否在输出中使用颜色 -e[scape] yes|no 在值中转义列分隔符 -a[sk] 询问缺少的参数 -s[how-secrets] 允许显示密码 -w[ait]

目录 文章目录 目录 基于 CI/CD 的 DevOps 思想 持续集成 持续交付 持续部署 DevOps 流程示例 基于 CI/CD 的 DevOps 思想 DevOps 是一组用于促进开发和运维人员之间协作的过程、方法和系统的统称 。 DevOps 提倡通过一系列的技术和工具降低开发和运维人员之间的隔阂，实现从开发到最终部署的全流程自动化，从而达到开发运维一体化。通过将 DevOps 的理念引入到整个系统的开发过程中，能够显著提升软件的开发效率，缩短软件交付的周期，更加适应当今快速发展的互联网时代。 一个 DevOps 环境应该满足以下 8 点需求： 环境一致性 ：在本地开发出来的功能，无论在什么环境下部署都应该能得到一致的结果。 代码自动检查 ：为了尽早发现问题，每一次代码提交后，系统都应该自动对代码进行检查，及早发现潜在的问题，并运行自动化测试。 持续集成 ：每次代码提交后系统可以自动进行代码的编译和打包，无需运维人员手动进行。 持续部署 ：代码集成完毕后，系统可以自动将运行环境中的旧版本应用更新成新版本的应用并且整个过程中不会让系统不可用。 持续反馈 ：在代码自动检查、持续集成、持续部署的过程中，一旦出现问题，要能及时将问题反馈给开发人员以及运维人员。开发和运维人员收到反馈后对问题及时进行修复。 快速回滚 ：当发现本次部署的版本出现问题时，系统应能快速回退到上一个可用版本