持续交付
文章平均质量分 71
rw-just-go-forward
这个作者很懒,什么都没留下…
展开
-
部署贴士和窍门
部署贴士和窍门真正执行部署操作的人应该参与部署过程的创建,项目开始时,让开发人员和部署人员都知道要做什么记录部署活动,特别是没有完全自动化的时候,人的记忆不靠谱不要删除旧文件新旧版本放在不同的文件夹下部署应该是所有人都会的活动服务器应用程序不应该有GUI,免除非要通过登录界面才能重启服务的尴尬为新部署留预热期,“金丝雀”发布快速失败,部署脚本也要有冒烟测试不要直接对生产环境进行任何原创 2016-04-15 08:27:21 · 651 阅读 · 0 评论 -
持续交付目录
基础篇《软件交付的问题》《配置管理》《持续集成》《测试策略的实现》部署流水线《部署流水线解析》《构建与部署脚本化》《提交阶段》《自动化验收测试》《非功能需求的测试》《应用程序的部署与发布》交付生态圈《基础设施和环境管理》《数据管理》《组件和依赖管理》《版本控制进阶》《持续交付管理》原创 2016-04-10 14:30:17 · 1622 阅读 · 0 评论 -
持续交付之六——构建与部署的脚本化
第六章 构建与部署的脚本化1. 引言要实现自动构建自动部署构建和部署系统一直要保持活力,这个系统不仅要从项目开始就开发,而且一直持续到产品到上线维护阶段,细心设计和维护它,像对待项目源代码一样,并定期使用,确保我们每次想用时,都能正确运行2. 构建工具概览由于我使用Java,用Maven构建,所以其他相关工具略过2.1. Make略2.2. Ant略2.3. NAnt与MSBuild略2.4.原创 2016-05-01 17:06:18 · 1627 阅读 · 0 评论 -
持续交付之七——提交阶段
引言提交阶段的目标目标主要有两个要么产生成功的可部署文件要么快速反馈失败的原因,并阻止部署流水线之后的进程,这样可以保证错误不向后续步骤蔓延提交阶段的开始和结束当向版本库中进行一次提交时,提交阶段就开始了,提交阶段是部署流水线的开始提交阶段的结果有两个成功,产生可供后续测试和发布的二进制产物和可部署程序集失败,得到失败报告提交阶段的原则和实践为了建立高效的提交阶段,需要遵循下列原则和实践原创 2016-04-10 13:28:25 · 1244 阅读 · 0 评论 -
持续交付之三——持续集成
其他持续交付相关文章:《持续交付》系列文章目录第三章 持续集成1. 引言持续集成的目标是让软件一直处于可工作的状态2. 实现持续集成2.1. 准备工作版本控制自动化构建团队共识2.2. 一个基本的持续集成系统开发人员使用持续集成服务的简单流程查看一下是否有构建正在运行,如果有的话,等它完事,如果它失败了,就和团队的其他人把他一起修复,然后再提交代码一旦构建完成且测试完全通过,就从版本控制原创 2016-05-08 08:45:34 · 1720 阅读 · 0 评论 -
持续交付之二——配置管理
第二章 配置管理1. 引言 定义: 配置管理是指一个过程, 通过该过程, 所有与项目相关的产物, 以及他们之间的关系, 都被唯一的定义, 存储, 检索和修改2. 使用版本控制2.1. 对所有内容进行版本控制至少要将那些用于重新创建应用程序的安装文件和安装环境所必需的所有信息保存在版本控制库中,包括代码文档工具构建环境的信息持续集成,自动化测试,一键式部署的前提都是所有与项目相关的内容原创 2016-05-07 08:39:34 · 2502 阅读 · 0 评论 -
持续交付之一——软件交付的问题
第一章 软件交付的问题1. 引言本书的核心模式是部署流水线,以持续集成理论作为其理论基石部署流水线有三个目标让软件构建,部署,测试和发布过程对所有人可见,促进合作改善反馈,能在整个过程中更早的发现和解决问题(做一件事,有问题发生是一定的,重要的是快速的定位和解决问题)使在任何环境下部署和发布任意版本的应用成为自动化的过程,提高效率一个简单的简单的部署流水线提交阶段 ==> 自动化验收测试 =原创 2016-05-07 07:30:23 · 7874 阅读 · 0 评论 -
idea中更改svn的commit message
在某些提交代码的时候,我们写的提交信息或者不完整,或者不准确,还有时候是因为懒,随便写了点乱七八糟的这种情况对项目的管理和以后问题的复查都是很大的阻碍所以,就需要可以更改svn的commit message,将已提交的信息改为合适的准确的信息在idea中可以这样干右键->Subversion->Show History在打开的history的tab中,右键你要修改的一条logEdit Revi原创 2016-08-27 09:58:10 · 8497 阅读 · 4 评论