关于代码管理和发布策略

在平时的开发过程中,版本的安排和发布对于一个完整的开发团队来说是比较重要的部分,这关系到版本能否按时递交和测试的质量的控制。

下面来说下本人在工作过程中版本的安排:

1,代码流和对应的环境

一般项目应该有至少4条流是比较正常的。

a, 本地测试环境(Main Test Env)---trunk

b,客户测试环境(UAT Env)---UAT流

c,生产环境(Production Env)------Prod流

d,特殊需求开(SP Env)-----CR流

2,代码流直接的关系

3,详细的merge过程如下:

4,解释说明:

<1>全量包发布

a)trunk流打包发布Main Test环境后,需要把Trunk流的代码merge到UAT流,trunk流开出来下个版本的开发。

b)Main Test环境测试通过后,把包发布到UAT环境并让客户测试。

c)客户在UAT测试出来的问题在UAT流修复,并打包UAT流发布到pre-UAT环境,测试通过后,发布到UAT环境。

d)UAT测试通过后,把包发布到pre-prod环境,进行回归测试,通过后把UAT流merge到Trunk流。

e)生产发布。

f) UAT流merge到Prod流。

<2>增量包发布

a)trunk流打包发布Main Test环境后,测试通过后,打trunk流的合包,然后把Trunk流的代码merge到UAT流,trunk流开出来下个版本的开发。

b)合包发布UAT并让那个客户验证。

c)客户在UAT测试出来的问题在UAT流修复,并打包UAT流发布到pre-UAT环境,测试通过后,发布到UAT环境。

d)UAT测试通过后,打UAT的合包,然后把包发布到pre-prod环境,进行回归测试,通过后把UAT流merge到Trunk流。

e)合包生产发布。

f) UAT流merge到Prod流。

时间: 2024-10-06 02:34:07

关于代码管理和发布策略的相关文章

Kubernetes资源扩容、项目发布策略

Master扩容 100台node,2台master足够了 这个在集群中讲过,可以参考之前的 Node扩容 这个在集群中讲过,可以参考之前的 Pod 扩容 以下是手动扩容为5个kubectl scale --replicas=5 deployment php-demo -n test 以下是手动缩容为3个kubectl scale --replicas=3 deployment php-demo -n test 自动扩容还得在研究 项目发布策略 蓝绿发布现在我们公司用的就是蓝绿发布策略A组 预发

技术团队代码管理和部署

主流公司使用svn和git作为代码版本管理,当然也不排除直接copy或者ftp.公司经历了的svn到git的变迁,也深刻体会到不同的版本管理服务,使得技术团队的协作方式变得更为流畅. 简单介绍下背景,有一个项目V5,从版本V1一直演变到现在V5,可见历史之久,想从svn切换到git,其中的代码管理和上线部署迁移,都会是经历很长一段时间的不稳定,尤其是一些开发同学对新的版本管理和部署理解不透彻,很容易引发事故. 在svn的主干开发流程 开发同学更新主干代码,提交代码 部署测试环境 检查每一个要上线

产品研发管理(二):使用SubVersion进行代码管理

概述 这是产品研发管理系列文章的第二篇:使用SubVersion进行代码管理. 介绍怎样使用SubVersion的资料已经很多,这里不准备介绍怎样使用SubVersion.这篇文章主要介绍怎样进行代码版本管理. 使用SubVersion进行代码管理 时间点(1) (1)的起始时间是3.0开发的开始. 在(1)期间,没有任何用户使用3.0(因为它还没有发布),所以所有开发人员直接在3.0Trunk上开发. (1)的结束时间是3.0开发的结束时间.结束时发布3.0产品,在SVN上创建3.0 Tag,

大作业01 代码管理仓库的开发

经过团队成员的讨论,一致决定开发一个本地代码管理工具.这个软件可以满足用户管理自己所编写的代码的需求. 团队成员: 王宏伟:外向.活泼.开朗.对软件的开发有着很高的热情. 蒋陵郡:成熟,热爱运动.管理能力强,工作态度认真负责. 唐炳辉:有思想,学习能力强,团队的技术骨干,脾气温柔. 邵文正:热爱编程,学习劲头足,工作也很认真. 项目简介: 现在还没有本地的代码管理工具,因此同学们写完程序后只是放在某个文件夹里面.保存在文件夹里面虽然很简单,但是也有一些弊端:首先,光从文件的名字上面很难看出这里的

ant发布web项目,tomcat管理界面发布war项目

今天用apache-ant-1.9.4 版本对 java web项目-adjustSolr 打包为war,并发布到tomcat中(一定要注意开发用的jdk版本和tomcat中的jdk版本一致,否则unsupport version51 错误) 贴build.xml文件的代码 <?xml version="1.0" encoding="UTF-8"?> <project name ="adjustSolr" default =&q

代码和产品发布的几种方式

代码和产品发布的几种方式 最近有几个朋友提起”灰度发布"这个概念和相关的问题.想解释一下几种具体的发布方式(具体名称中文翻译不一定正确).他们的优缺点和实现难点. 这几种方式都可以作为快速运营的软件或者web服务公司逐步发布新代码或者新产品,边尝试边改进的方法,这些方法可以避免一次发布里面某个产品/代码的漏洞对网站产生瞬间毁灭性的后果. 这几种方式各有优缺点和难点,根据实际情况一个公司可能使用不同的方法做不同的发布. 分步代码发布(multi-phase code push):这是敏捷开发的团队

python的模块管理与发布+如何在pypi上发布自己的模块

1.安装模块 1.1,从源码安装 找到代码的url,一般在开源托管平台上有,再wget或git克隆下来,tar解压,如果有setup.py文件则运行此文件,如果没有按照INSTALL或README文档安装运行,从pypi中央仓库中下载源码的话一定有setup.py 1.2,模块管理工具来安装 pip,easy_install 用这个方法有个好处就是版本控制和依赖的处理.在这两种方法里面一般用pip,因为用pip更省事.与设置yum的本地源一样也可以通过设置pip的本地元为国内的源豆瓣镜像,具体方

大作业一 代码管理仓库的开发

经过团队成员的讨论,一致决定开发一个本地代码管理工具.这个软件可以满足用户管理自己所编写的代码的需求. 团队成员: 王宏伟:外向.活泼.开朗.对软件的开发有着很高的热情. 蒋陵郡:成熟,热爱运动.管理能力强,工作态度认证负责. 唐炳辉:有思想,学习能力强,团队的技术骨干,脾气温柔. 邵文正:热爱编程,学习劲头足,工作也很认真. 项目简介: 现在还没有本地的代码管理工具,因此同学们写完程序后只是放在某个文件夹里面.保存在文件夹里面虽然很简单,但是也有一些弊端:首先,光从文件的名字上面很难看出这里的

代码管理器 TFS2013

多人开发代码管理器肯定是少不了的,出于项目需要在服务器上装了tfs2013用于代码管理,既然用vs进行开发自然选择微软自家的tfs.记录下安装和使用起来的过程. 安装 TFS2013(Team Foundation Server 2013 下载),安装就按引导下一步就好了. 配置 基本 选项进行配置,然后点击启动向导,根据向导完成配置. 打开http://localhost:8080/tfs如下图,安装完成. 添加用户 打开http://localhost:8080/tfs进行设置.添加wind