应用生命周期管理(ALM)挑战的一个最大挑战是处理应用部署任务。这个过程可能会很复杂,可以多管齐下,与许多不同的组件和块相互作用最终构建,发送生产。另外,部署应用程序产生问题的部署,就是ALM流程最显而易见的部分。 总之,如果一个正在工作的应用突然停止工作了,从资深管理者到终端用户的所有人都会被问到出什么错了这个问题,并作出回答。
幸运地,有许多最佳实践,项目经理和DevOps经理从中了解它可以帮助改进部署流程。遵循这些指导方针,你很有可能会在应用程序发布后避免遇到问题。 现实核查 在一个高仿真的真实生产环境的沙盒中测试部署对于成功很重要。不过,许多企业让他们试制服务器及其实时服务器……
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
应用生命周期管理(ALM)挑战的一个最大挑战是处理应用部署任务。这个过程可能会很复杂,可以多管齐下,与许多不同的组件和块相互作用最终构建,发送生产。另外,部署应用程序产生问题的部署,就是ALM流程最显而易见的部分。
总之,如果一个正在工作的应用突然停止工作了,从资深管理者到终端用户的所有人都会被问到出什么错了这个问题,并作出回答。幸运地,有许多最佳实践,项目经理和DevOps经理从中了解它可以帮助改进部署流程。遵循这些指导方针,你很有可能会在应用程序发布后避免遇到问题。
现实核查
在一个高仿真的真实生产环境的沙盒中测试部署对于成功很重要。不过,许多企业让他们试制服务器及其实时服务器变得与更新和升级发生的不同步。确保测试服务器和生产服务器尽可能的保持相同,使其成为操作系统补丁或配置文件设置。在部署中一个小的偏差很可能造成深远的负面影响。
记住,典型的测试环境只是给你展示出应用在完美的世界中是怎样执行的。当然,你可以改变参数,扩大或缩减,但这仍相当于一个有经验的车手在一个不错的、笔直的、没有阻塞的高速公路上测试一辆车。但我们仍旧无法预知每一个外力或最终用户的习惯,这可能会打破你的应用程序。
你需要一个测试环境,并尽可能地使其接近生产环境。有些情况下,那意味部署到一个Web可访问的状态环境下。或者,你可以在你组织的硬盘和基础设施上部署,但是要暂时配置服务负载,这样才能只有测试团队有权限访问应用程序的测试版本。
亲自动手实践部署测试
当你测试你的部署时,站在终端用户的角度,有几件是你应用进行测试,但不仅仅只是通过运行匿名脚本。内容交付网络是怎样影响你的应用的性能的?它在真实浏览器(包括旧的版本,如果有些用户不打算更新到最新版本)上是否渲染的好,是功能是否合适?防火墙和Web服务器是不是限制了对特点文件和脚本的权限?组件和扩展功能是否和预想的一样,或者他们将会导致在高负载下不容接受的很长运行时间?这些问题都是自动脚本不能解答的问题。
以人为本
谨记,部署不仅仅只是技术流程——它是人们的努力,而且它需要团队方法来获得成功。IT项目经常会远远超过他们项目的完成日期,但这并不意味着该项目在部署时应该让每个人都加班工作。过度开发团队将导致疲惫的开发者,而且在项目越接过末尾时,当你几乎准备好推出时,越容易产生更多的错误。
当然,不只是你团队的成员在成功部署中占有重要地位。你组织内外不同的利益相关者,以及终端用户同样也很重要。了解他们的需求和期望,否则你的部署可能会因为他们的反对,要求改变而付之东流。这在大的组织中尤其是真理,因为组织存在很大的风险,一旦预定的部署不能满足他们的需求,就会有人把事情搅乱。
自动化和ALM
在几乎所有地案例中,手动部署是效率最选择,而且自动化现在在应用生命周期管理(ALM)中是一个强制性的部分。手动流程更有可能是产生错误,而且不是消除错误。牺牲一个员工来手动执行一个很容易自动化的任务,只是在浪费资源,这一事实变得越来越明显和大规模、频繁地部署。花点时间来引入可靠的、模块化自动化工具或脚本,从而尽可能多地处理ALM流程,这包括:
-负载测试和性能测试
-为分布鉴别文章和打包文章之间的依赖关系
-在目标环境中安装
-配置管理和变更管理
修剪项目
随着项目变旧出现了一种倾向,过多的文件和资源仍然作为部署的一部保留着,尽管不在应用程序的任何地方使用或调用。时常修剪应用程序一直都是一个好办法。查看一下文件、目录、模块和其他的与部署、使用、维护和运行应用程序相关的资源。如果有不用的,就不要把它包含在内。有一些IT项目经理建议剔除所有旧的文件和,同时也从生产系统中删除旧的版本。
归档、归档、再归档
文档管理是你的老朋友。确保代码本身、所有组件相互适应的方式、部署的计划/原则/流程/协议、故障排除、维修和使用培训/说明有具体的、准确的文档。不久的将来,你会发现你将会重用很多这些信息。你的团队会很高兴不用每次都重写这些,而你的利益相关者将会感动于你的快速,可靠的部署。
另外,如果最初设置部署过程的人已经离开,那么有人就会希望你能够追溯他们的步骤和复制他们创建的过程。不要让部署流程相关的知识消失,因为维护它的员工离开了公司。
适时停止
当然,你应用随时做出最坏的准备,这意味着永远不要没有计划去部署,因为一旦它运行的不好,重新安装。这包括编写和测试脚本。确保这计划也利益相关者沟通过,这样一旦在部署过程中出现错误他就会了然,那么你至少可以回到临时工作时的最新版本。
同样,在面对不确定性时做法大胆有时是不明智的。作为一个部署前的策略,确定在哪里停止,评估你否真的准备好向前推进,或者是否应用推迟或停止流程,要确定这些点。在生产部署前识别并修改问题,总是件好事。安抚焦躁的利益相关者是你可以较好管理的一件事,这比管理因错误部署打乱了关键业务流程,打破了客户的美好期望而生产的抱怨好多了。
相关推荐
-
多云工作负载迁移:自动化是何作用?
云计算正在发展进入一个崭新的、更成熟的阶段。云规划和部署的关注点已经从低效应用的远程托管转至对云的支持,并将其作为开发人员所使用的虚拟应用平台。
-
你的微服务设计支持可重用并避免冗余吗?
微服务是代码小型的功能捆绑,旨在通过适当的使用来促进可重用并改善QoE以及可用性。如果使用不恰当的话,它们就会成为应用生命周期管理和资源效率的“噩梦”。
-
对于orchestration而言 ALM和DevOps至关重要
为了确保开发和运营能够持续同步演进,开发者需要理解DevOps与orchestration之间的差异,对自己的开发和运营策略进行重新思考,并且对重要的新兴趋势保持警觉。
-
Puppet Enterprise为自动化提供陈述性解决方案
Puppet令组织科做出快速、可重复的变更,同时还可以自动确保云端或本地跨物理机与虚拟机(VM)的系统和设备的一致性。