帮助管理企业环境中的应用程序升级过程的工具

通过谷歌很难找到一个好的。现在有大量用于问题管理的工具,所以我将提到我们使用什么以及我们想使用什么。

我们目前使用的是Serena产品。过去他们为我们工作得很好。团队跟踪是我们的问题管理,处理我们所处理的任何问题的生命周期。版本管理器是我们的源代码管理,它具有实现诸如dev test和prod之类的推广组的特性。我们使用dev、tstage、test、pstage和prod来表示从一个到另一个的移动,但这几乎是相同的。这两个产品很好地集成在一起,以便与问题相关联的源代码被链接起来,但是我们在这个环境中没有构建过程设置。它很贵,但效果很好。

我们正在寻找一个更常见的系统,使用JIRA进行问题管理,颠覆源代码控制,鱼眼将两者连接在一起,巡航控制进行构建管理。这样做成本较低,一个企业级的Lisence总共有几千个,提供了所有相同的功能,但是SVN的额外功能是一个非常好的代码版本管理器。

希望有帮助。

这些年来,我经历了几个不同的场景:

dev->测试:通常有一个代码冻结日期,它停止对新功能的工作,并使测试环境获得已被标记/标记/存档并生成的代码。然后这个被复制到机器上,测试就正常了。这通常也是最不详细的推送。

test->prod:这需要对生产进行较小的更改,这可能意味着“消失的钓鱼”页面会上升,或者IIS没有任何正在运行的站点,代码会再次被复制。在这种情况下,负载均衡器可以充当一个开关,这样促销就发生了,而且没有任何客户体验到任何停机时间,因为旧服务器上的客户在会话结束后都将移动。

为了详细说明这种切换思想,设置是让两个潜在的活动服务器,其中一个服务器接受负载均衡器只是将所有流量发送到一台机器的请求,当另一台服务器有更新的代码投入使用时,可以切换到另一台机器。

在测试和生产之间也可以有一个登台环境,在这个环境中,流程类似,因为促销发生时有一个固定的日期。

在我以前工作的地方,会有一些合并的日子,开发人员花了一天的大部分时间来执行合并代码,以便将代码从一个环境提升到另一个环境。

现在有两种情况没有用到:

“热修复程序”或“热修补程序”会出现在我以前工作的地方,在这种情况下,特定的文件会自己复制到登台和生产环境中,因为代码更改必须尽快进入生产环境,因为生产中发生了一些事情,或者必须完成的一些新事情需要2分钟才能完成。在这种情况下,推入的代码更改必须在退出之前经过审查和批准。

这些是我所看到的不同的方法,通常都有时间表和时间表,可能需要更改,或者需要额外的资源来安排一个艰难的日期,比如某个会议在某个周末举行,这样的和那样的会议已经准备好了。

当然,在一些地方,“哦,那个坏了吗?让我想想……”几分钟后,“不,看它对我来说没有坏,”有人在没有得到许可的情况下改变了事情,或者公司仍然拥有他们所说的“牛仔编程”。

另一点是发布的规模: 1)很小-这是一个网页向上的情况,这样用户x可以做y。

2)小文件-一小部分文件,这些文件不是很复杂,但也不是很简单。

3)中等-从一个环境到另一个环境需要更改一组文件,通常需要移动脚本。

4)大-有计划的促销活动,并要求不同的开发人员在现场推送完成后轮班。我有这样一个例子,除了发布一些新的电子商务站点外,还需要进行数据迁移。

5)猛犸象-所有东西都是全新的,包括如何使用。我不认为我见过这样的版本,但我可以想象微软或谷歌会有这样的版本。

在这个范围内的某个地方,大多数发布都会下降,所以计划和准备工作的程度可能会有很大的不同,我们不要忘记,法规遵从性可能是完成某些工作的自身痛苦。