标签：项目 DevOps devops 发布 阶段 测试 融合 团队
devops是什么？
DevOps 对团队意味着什么？DevOps 使以前孤立的角色（开发、IT 运营、质量工程和安全）可以协调和协作，以生产更好、更可靠的产品。通过采用 DevOps 文化、做法和工具，团队能够更好地响应客户需求，增强对所构建应用程序的信心，更快地实现业务目标。
devops好处？
采用 DevOps 的文化、做法和工具的团队将获得高绩效，可以用更快的速度构建更好的产品以获得更高的客户满意度。若要实现以下业务目标，这种改进的协作方式和生产能力不可或缺：
-
缩短上市时间
-
适应市场和竞争
-
保持系统稳定性和可靠性
-
缩短平均恢复时间
devops对比其他模式：
敏捷开发可以帮助更快地发现问题，产品被更快地交付到用户手中，团队可以更快地得到用户的反馈，从而进行更快地响应。而且，DevOps小步快跑的形式带来的版本变化是比较小的，风险会更小（如下图所示）。即使出现问题，修复起来也会相对容易一些。
devops文化：
虽然采用 DevOps 做法可以通过技术自动化和优化流程，但这一切都是从组织内部的文化和参与的人员开始的。培养 DevOps 文化的挑战在于需要深入改变人们的工作和协作方式。但是，当组织致力于 DevOps 文化时，可以创造一个让高绩效团队培养文化的环境。
-
协作、可见性和一致性
健康的 DevOps 文化的一个标志是团队间能够协作，首要的便是可见性。开发和 IT 运营等不同团队必须能够相互分享 DevOps 流程、优先级和关注点。这些团队还必须能够共同规划工作，并统一与业务相关的成功目标和衡量标准。 -
范围和责任的转变
当团队统一时，他们拥有所有权并参与其他生命周期阶段，而不仅仅是他们的角色对应的阶段。例如，开发人员不仅要对开发阶段的创新和质量负责，还要对他们的改变在运营阶段带来的性能和稳定性负责。同时，IT 操作员一定要在规划和开发阶段中包括治理、安全性和符合性。 -
缩短发布周期
DevOps 团队通过短周期发布软件保持敏捷。因为进度是渐进式的，缩短发布周期可以让计划和风险管理更容易，同时也减少了对系统稳定性的影响。缩短发布周期还可以让组织适应和应对不断变化的客户需求和竞争压力。 -
持续学习
高绩效的 DevOps 团队形成了一种成长思维。他们快速失败，然后将经验教训融入到他们的流程中，不断改进，提高客户满意度，加速创新和适应市场。DevOps 是一个旅程，所以总有成长的空间
devops生命周期：
DevOps 影响应用程序生命周期的规划、开发、交付和运营阶段。每个阶段都依赖于其他阶段，并且这些阶段并非特定于角色。在真正的 DevOps 文化中，每个角色在某种程度上都涉及到每个阶段。
- 计划
在规划阶段，DevOps 团队构思、定义和描述他们即将构建的应用程序和系统的特性和功能。他们在低粒度和高粒度级别上跟踪从单个产品任务到跨多个产品组合的任务进展。DevOps 团队以敏捷和直观地方式进行规划的一些方法包括创建积压工作 (backlog)、跟踪 bug、使用 scrum 管理敏捷软件开发、使用看板以及使用仪表板直观呈现进度。 - 开发
开发阶段包括编码的各个方面（编写、测试、评审）、团队成员集成代码，以及将代码构建为可部署到各种环境中的生成工件。DevOps 团队寻求在不牺牲质量、稳定性和生产效率的情况下快速创新。为此，他们使用高效的工具、自动化单调和手动步骤，并通过自动化测试和持续集成以小增量迭代。 - 传送
交付是以一致且可靠的方式将应用程序部署到生产环境中的过程。交付阶段还包括部署和配置构成这些环境的基础结构，该基础机构受到完全治理。
在交付阶段，团队定义了具有明确手动批准阶段的发布管理流程。他们还设置了自动入口，用于推动应用程序经历各个阶段，直到提供给客户。这些流程的自动化使这些流程可伸缩、可重复并且可控制。这样，使用 DevOps 的团队就可以轻松、自信、放心地频繁交付。 - 运营
运营阶段包括维护、监视和对生产环境中的应用程序进行故障排除。在采用 DevOps 做法时，团队致力于确保系统的可靠性、高可用性，并在加强安全性和治理的同时实现零停机的目标。DevOps 团队希望在问题影响客户体验之前发现问题，并在问题发生时迅速解决问题。保持这种警惕性需要丰富的遥测、可操作的警报以及全面了解程序和基础系统。
devops实施：
需要用到的工具说明
- 蓝湖
是一款产品文档和设计图共享平台，帮助我们更好的管理文档和设计图 - GitLab
开源的版本管理系统，是一个基于Git实现的在线代码仓库托管软件，集CI/CD流水线管理 - sonarQube
一款可持续检测的源代码工具，支持代码静态扫描，缺陷、漏洞、编码规范，重复度等多维度分析，帮组我们提升代码质量 - 禅道
主要是对软件缺陷进行跟踪处理，记录测试活动发现的缺陷和改进建议，并可以输出测试分析报告和统计报表 - Jenkins
一种持续集成工具，用于持续发布/测试项目，并可监控外部调用执行的工作
持续集成和持续交付 (CI/CD)流程图
整体架构
部分细化图：
持续集成和持续交付 (CI/CD)步骤说明
- 项目经理把项目需求，提交蓝湖， UI设计师根据需求把UI效果图设计好发布到蓝湖。
- 开发工程师到蓝湖上获取任务，通过UI效果图设计好数据结构等，开始编码，并把编写好的代码提交到GitLab（dev）分支
- 开发工程师也可以通过sonarQube扫描，改进自己的代码，帮助提升代码质量
- 开发工程师通过Jenkins发布到开发环境，自测后把代码同步到GitLab 测试（test）分支
- 测试工程师通过Jenkins拿测试(test)分支代码部署到测试服务器，通过自动化测试、核心业务测试，如果测试出BUG则提交到禅道
- 开发工程师通过禅道BUG单，逐一修改BUG，并通过 Jenkins 发布到开发环境自测，如通过再提交到GitLab 测试（test）分支
- 测试工程师重复步骤5
- 开发工程师把BUG全部修改完毕，测试工程师测试完BUG， 经过评审可以发布，那么把GitLab 测试（test）分支提交到GitLab（master）分支，并通过Jenkins 发布到正式环境
说明：一般来说还有一个预发布环境，就是正式环境的克隆，先发布到预发布环境验证，如果完全没有问题则正 式发布到线上。由于我们没有这个环境，故减少这一步骤
标签：项目,DevOps,devops,发布,阶段,测试,融合,团队 来源： https://www.cnblogs.com/harry66/p/16504328.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。