• [专题汇总] 【产品评测】华为软件开发云评测文章汇总
    为方便大家阅读,版主整理了所有华为软件开发云功能测评方面的文章,具体如下:1、文章标题:华为软件开发云之初体验文章地址:https://portal.hwclouds.com/blogs/bf569f1bc1e411e6b8317ca23e93a8912、文章标题:如何使用华为软件开发云快速部署PHP网站文章地址:https://portal.hwclouds.com/blogs/30e1a875621711e7b8317ca23e93a8913、文章标题:华为软件开发云测评报告一 : 项目管理文章地址:https://portal.hwclouds.com/blogs/b9c57af1653e11e7b8317ca23e93a8914、文章标题:华为软件开发云测评报告二: 代码检查文章地址:https://portal.hwclouds.com/blogs/57792a5c654311e7b8317ca23e93a8915、文章标题:华为软件开发云测评报告三:测试管理文章地址:https://portal.hwclouds.com/blogs/d21612ca7e4611e7b8317ca23e93a8916、文章标题:测评:华为最新移动应用/APP测试工具MobileTest文章地址:https://portal.hwclouds.com/blogs/ed7c4dbb621611e7b8317ca23e93a8917、文章标题:华为软件开发云发布管理测评报告文章地址:https://portal.hwclouds.com/blogs/2944172e7d9411e7b8317ca23e93a8918、文章标题:华为软件开发云:一站式研发利器文章地址:https://portal.hwclouds.com/blogs/0a85b2cdbc3011e6b8317ca23e93a891
  • [技术交流] 纯干货!华为软件开发云编译构建之Maven
    一.Maven介绍Maven是一个项目管理和整合的工具。Maven为开发者提供了一套完整的构建生命周期框架。开发团队基本不用花多少时间就能自动完成工程的基础构建配置,因为Maven使用了一个标准的目录结构和一个默认的构建生命周期。二.Maven用途Maven提供了帮助管理构建、文档、报告、依赖、SCMs、发布、分发的方法。可以方便的编译代码、进行依赖管理、管理二进制库等等。Maven的好处在于可以将项目过程规范化、自动化、高效化以及强大的可扩展性利用Maven自身及其插件还可以获得代码检查报告、单元测试覆盖率、实现持续集成等等。三.Maven配置1. 新建构建任务首先在华为软件开发云 中新建构建任务(见图1)。图1 新建构建任务【maven-demo】是用户自定义的构建任务名称。【maven_demo】是已经创建的代码仓库,【master】是【maven_demo】中的一个分支。关于归档,需要注意两点:1)归档的路径,默认是【target/*.jar】,实际路径取决于pom文件的路径,我们先看【maven_demo】的工程目录(见图2),pom文件在【springmvc_demo】文件夹内,所以实际归档的路径应该是【springmvc_demo/target/*.jar】。图2 maven_demo仓库目录结构2) 归档类型,默认是jar,实际类型取决于pom文件中的设定(见图3),pom文件中,打包类型是war,所以实际类型是war。图3 springmvc_demo工程pom文件所以,归档中,应该写入【springmvc_demo/target/*.war】。最后,成功创建构建任务。2. 编辑构建任务1) 基本信息创建任务时的配置是最基本的配置,用户可以通过编辑任务配置更详细的参数(见图4)。图4 构建任务编辑步骤在【基本信息】中,可以设定【执行参数配置】,也就是在执行构建的时候,进行参数配置。这些参数主要用于设置【包名】、【版本号】、【分组】和【打包类型】,在【配置构建】中会使用这些参数(见图5)。 图5 执行参数配置【字符类型】就是字符串,【自定义类型】类似于枚举,从定义好的值中选择一个(见图6,图7)。 图6自定义类型参数编辑 图7 自定义类型参数值2) 代码配置选择要构建的代码仓库和分支(见图8)。图8 选择一个代码仓库如果选择【自动构建】,则只要仓库代码有变动,就会触发编译构建。根据项目需要,如果要构建多个仓库,为了避免代码冲突,需要指定存储目录(见图9)。 图9 选择多个代码仓库该存储目录由用户自定义设置,在服务器中对应的路径与仓库的目录结构有关。【maven_demo】的构建路径如下图: 图10 maven_deno仓库的工作目录【maven_demo2】的构建路径如下图: 图11 maven_deno2仓库的工作目录注意:仓库【maven_demo2】的目录结构与仓库【maven_demo】的不同,前者的pom文件在仓库的根目录下,后者的pom文件在根目录下的【springmvc_demo】目录中。3) 构建配置构建环境选择【Java】,构建类型选择【Maven】。Maven的配置参数很多(见图12)。图12 maven参数配置【Maven版本】:目前只支持mvn3.3.1,之后会根据maven的版本升级而更新可选择的版本号。【发布到私有库】:默认不选是执行mavenpackage,打包到本项目,一般是在项目target目录下。如果勾选,则执行mavendeploy,打包上传到远程仓库,将软件包发布至用户私有maven release和maven snapshot仓库,需要配置pom文件。【Maven参数】:默认是-U,在编译的时候会下载snapshot仓库的最新依赖包。如果有需要可以配置其他的参数(见图13)。 图13 maven常用参数命令【POM文件】:如果pom文件在仓库的根目录下,则不用填写,如果像仓库【maven_demo】,pom文件不在根目录下,需要指定pom文件的路径【springmvc_demo/pom.xml】,如果在【代码配置】中,指定了【存储目录】为test1,则需要要加上存储目录,即【test1/springmvc_demo/pom.xml】。【属性】:即构建脚本需要的属性。用命令行使用Maven的插件时,-D表示属性的输入。例如maven的版本管理,增加属性如下(见图14):#Maven 版本管理branchName=xxxx-100317 #分支中的名称updateBranchVersions=false #是否更新分支的版本信息,默认为falseupdateWorkingCopyVersions=false #是否更新主干的版本信息,默认为true每个属性中不能有空格,属性之间用空格分开。 图14 maven属性配置具体如何查找属性请参考下面链接:http://www.cnblogs.com/EasonJim/p/6865150.html【JVM选项】: 在基于Maven管理的Java项目中,经常出现内存溢出的错误,这种情况下,需要进行JVM的参数设置更新,一般而言,都是根据内存溢出问题的不同,针对内存、permspace来进行调整和设置。比如增大PermGen区空间为128M,设置方法为setMAVEN_OPTS=-XX:MaxPermSize=128M,实际填写【JVM选项】时,只写入【-XX:MaxPermSize=128M】(见图15),如果需要设置多个属性,属性之间用空格分隔。 图15 maven JVM选项配置JVM的具体参数请参考下面的链接:http://www.oracle.com/technetwor ... ons-jsp-140102.html【编译构建 后】选择【发布到编译构建仓库】(见图16)图16 编译构建后参数配置这里,会定义【包名】、【版本号】、【文件路径】、【分组】和【打包类型】,这里可以写入固定的值,也可以使用在【基本信息】中定义的参数,这里使用的就是【基本信息】中定义的参数。方法是${参数名}。关于【文件路径】,如果pom文件在仓库的根目录下,并且没有指定【存储目录】,则【文件路径】为【target/springmvc_demo.war】,如果指定了【存储目录】为test1,那么在【文件路径】最前面应该加上存储目录,例如【test1/springmvc_demo/target/springmvc_demo.war】。如果同时构建多个仓库,则需要再增加【执行Maven】和【发布到编译构建仓库】步骤(见图17)。图17 多仓库编译构建后参数配置4) 构建执行配置【构建结果】选择【归档】,【用于归档的文件】默认就是全部包(见图18)。具体路径也是取决于pom文件的路径,参考【构建配置】中的【文件路径】。 图18 构建结果配置包的类型取决于pom文件中的定义。【不包含】是指不需要归档的包,如果有多个,每个包之间用空格分隔。如果选择多个代码仓库,则需要增加【归档】(见图19)。 图19 多仓库构建结果配置5) 构建计划配置【构建计划】有【不定时】、【每日】和【每周】。【不定时】是指用户手动构建,用户不操作,就不会构建。【每日】是指每天定时构建,不需要用户操作(见图20)。图20 每日构建计划配置【每周】是指每周可以固定哪几天定时构建,如周二,周四(见图21),也不需要用户操作。 图21 每周构建计划配置【构建时长限制】是指一次构建最长时间限制,如果超过该时长还没有构建完毕,则停止构建。四.Maven构建用户执行【开始构建】,会弹出参数窗口(见图22)。 图22 执行构建配置根据项目实际需求,填写参数,这些参数是在【基本信息】中定义好的,然后开始【执行】,最后构建成功(见图23)。图23 构建成功五.小结maven不仅是构建工具,它还是依赖管理工具和项目管理工具,提供了中央仓库,能够帮我们自动下载构件。为了解决依赖的增多,版本不一致,版本冲突,依赖臃肿等问题,它通过一个坐标系统来精确地定位每一个构件。maven还为全世界的Java开发者提供了一个免费的中央仓库,在其中几乎可以找到任何的流行开源软件。通过衍生工具(nexus),我们还能对其进行快速搜索。总之,maven构建会给你带来很多的好处和惊喜。
  • [视频] 华为软件开发云的DevOps实践
  • [技术交流] 软件开发过程中你遇到过最让你目瞪口呆的bug是什么样的?
       你在软件开发过程中遇到过什么奇葩的bug呢?说出来,让大家见识一下。
  • 敏捷开发和迭代开发是一回事么?
    在这敏捷开发横行的时代中,人人都在谈敏捷,人人都在谈迭代,似乎大家好像都尝到了敏捷带来的甜头,记得有一次跟朋友吃饭,说他们现在的项目用敏捷开发,每个迭代都能看到不断完善的产品,非常有成就感,客户的满意度也提升了不少;另一个朋友说,我们用迭代开发,也是这样,而且客户想加什么需求就加什么,直接按照优先级排到迭代周期就行,也不用为改需求而烦躁。当时我就想,敏捷开发不就是分迭代周期的吗,他俩好像说的是一回事吧。回去过了好长一段时间,突然想起这件事了,在网上一查,还真不是一回事… 33.jpg (21.11 KB, 下载次数: 5)下载附件 保存到相册 2017-8-14 16:05 上传 迭代开发流程:什么叫迭代开发?在迭代开发中,整个开发工作被组织为一系列的短小的、固定长度(如3周)的小项目,被称为一系列的迭代,这叫迭代开发。每一次迭代都包括了定义、需求分析、设计、实现与测试。而敏捷开发是以用户的需求进化为核心,采用迭代、循序渐进的方法进行软件开发。前者是软件开发的生命周期模型,是一种开发过程;后者是多种软件开发项目管理方法的集合,是一种开发方法。这是两者最根本的区别。与迭代开发对应是瀑布模型,螺旋模型等,而与敏捷开发对应的是Scrum,XP(极限编程),Crystal(水晶编程)等开发方法,所以它俩根本就不是一回事!那么它们俩有没有关系呢?答案是:有…敏捷-Scrum开发流程: 34.jpg (50.12 KB, 下载次数: 5)下载附件 保存到相册 2017-8-14 16:06 上传 敏捷开发的定义就已经说明,采用迭代的方法进行软件开发。那么有人会问,敏捷开发为什么要采用迭代开发呢?不要忘了敏捷开发的核心原则是拥抱变化,和递增的变化。迭代式开发正适合在那些需求信息不明确的项目,这样在开发过程中遇到需求的变化时,所带来的影响要比其他模型小。而现在的很多项目中,需求在项目进行中变化的事儿经常见,所以显得迭代式开发的优势更明显一些,这正符合敏捷开发的拥抱变化。而且迭代开发是不要求每一个阶段的任务做的都是最完美的,明明知道还有很多不足的地方,却偏偏不去完善它,而是把主要功能先搭建起来,以最短的时间,最少的损失先完成一个“不完美的成果物”直至提交,然后再通过客户或用户的反馈信息,在这个“不完美的成果物”上逐步进行完善,这正符合敏捷开发的递增变化。当然,敏捷开发只是一个总体概念,而迭代式开发只是几乎所有敏捷开发所采用的一个主要的基础实践。敏捷开发除迭代式开发外,还包含了其他许多管理与工程技术实践,如演进式架构设计、敏捷建模、重构、自动回归测试(ART)等等。总而言之,就是敏捷开发与迭代开发是整体与局部的关系,前者就像大家庭,而后者是大家庭中的一员。 敏捷发展历史 35.jpg (32.55 KB, 下载次数: 5)下载附件 保存到相册 2017-8-14 16:06 上传 敏捷和迭代虽然不一样,但是它们也是分不开的,迭代和敏捷开发方式的结合,既保证了产品的质量又在项目产品的持续改进中具有一定的优势。吸取精华,破其糟粕,只有这样,项目才会达到趋于完美的程度。我们的项目管理工具-华为软件开发云就很好的把敏捷和迭代完美的融合到一起了,并且还配备代码管理,代码检查,编译构建,部署和发布等一站式的流水线开发流程,大大提高了我们管理和开发人员的工作效率,这也是我们所有IT人,做任何项目都想达到的目标。
  • [技术干货] 【产品评测】华为软件开发云评测文章汇总
    为方便大家阅读,版主整理了所有华为软件开发云功能测评方面的文章,具体如下:1、文章标题:华为软件开发云之初体验 文章地址:https://portal.hwclouds.com/blogs/bf569f1bc1e411e6b8317ca23e93a891 2、文章标题:如何使用华为软件开发云快速部署PHP网站 文章地址:https://portal.hwclouds.com/blogs/30e1a875621711e7b8317ca23e93a891 3、文章标题:华为软件开发云测评报告一 : 项目管理 文章地址:https://portal.hwclouds.com/blogs/b9c57af1653e11e7b8317ca23e93a891 4、文章标题:华为软件开发云测评报告二: 代码检查 文章地址:https://portal.hwclouds.com/blogs/57792a5c654311e7b8317ca23e93a891 5、文章标题:华为软件开发云测评报告三:测试管理 文章地址:https://portal.hwclouds.com/blogs/d21612ca7e4611e7b8317ca23e93a891 6、文章标题:测评:华为最新移动应用/APP测试工具MobileTest文章地址:https://portal.hwclouds.com/blogs/ed7c4dbb621611e7b8317ca23e93a891 7、文章标题:华为软件开发云发布管理测评报告 文章地址:https://portal.hwclouds.com/blogs/2944172e7d9411e7b8317ca23e93a891 8、文章标题:华为软件开发云:一站式研发利器 文章地址:https://portal.hwclouds.com/blogs/0a85b2cdbc3011e6b8317ca23e93a891
  • 【软件开发交流】DevOps团队之殇
    “你在团队里是做什么的?” “DevOps。” “DevOps是什么呢?” “DevOps是一种文化、一种实践,目标是加快软件迭代速度,让团队更快交付价值。” “能不能具体点,你们日常工作的主要内容是什么?” “修Pipeline...”作为一名开发,在刚涉足DevOps领域的时候,最难的就是和传统运维撇清关系;等到DevOps不再被当成是运维,又容易被当成是专职修Pipeline的人。DevOps在一遍遍被人们提及、一次次在项目中被实践时,也在不断地被重新定义,DevOps是什么?这个问题可能到现在也比较难说清楚,但是项目中的“DevOps”做了些什么,却是清晰可见的。 本文就结合笔者的切身经历,谈一谈关于DevOps交付的价值以及在企业转型过程中遇到的一些问题。背景介绍客户是一家澳洲大型金融保险企业,其IT部门总人数在千人以上,维护应用两百余个。在经历了几年的收购和合并之后,在业务上指定了“将收购来的多个品牌进行整合”的大方针,于是IT部门也开始面临系统整合、业务线整合、网站合并的问题,同时客户正在将他们的服务逐渐从自建数据中心向AWS公有云服务上迁移。团队概览在数字化转型的漫漫长路中,该企业已经在内部搭建起了一套持续交付系统,以Jenkins为中心,有制品库、依赖管理、代码管理、任务管理系统,敏捷实践成熟。 我所在的团队是在整个组织向DevOps转型中的一个比较关键的团队,肩负着CI/CD优化、持续交付改进、运维能力输出的重任。类似的团队应该在很多DevOps转型的组织里都有,负责维护CI/CD基础设施、搭建应用开发脚手架、维护基础设施变更、做各种自动化的工作(姑且就将这类团队称之为Platform团队)。比较特殊的是我在的这个团队实行轮岗制,由产品团队的成员(通常是开发人员)定期轮换到Platform团队,带着在产品团队遇到但是没能解决的问题,在这个团队中寻求最佳实践和解决方案,一段时间后(通常是三个月),开发人员从Platform团队回到开发团队,同时将DevOps技能和最佳实践带到产品开发团队。 整个Platform团队基本维持在3-5人的规模,有一个IM(Iteration Manager迭代经理),其余全是开发人员。取得的成就 回顾过去的五个月,Platform团队一共经历了10个迭代(每个迭代两个星期),我梳理了一下每个迭代的工作内容,整理出主要成就如下:[*]围绕CI/CD做了很多优化,比如简化Jenkins slave创建流程、给自动化脚本(基础设施代码)贡献了许多新功能。[*]新技术试点,比如尝试将静态文件部署到AWS S3中代替Apache服务。[*]为应用设置监控,更新了基础设施脚本用于开启监控,并协助应用团队将配置脚本应用到各个环境。[*]团队之间的沟通,了解开发团队痛点,帮助开发团队找到能够解决问题的团队(权限、责任划分、知识传递),技能培训等。[*]响应变化,解决技术难题(虽然我认为这更像是一个沟通+权限的问题,但是其他所有团队都认为是技术难题,那我也就这样认为吧),以及修复一些类似于硬盘空间已满、网络延迟、权限的问题。遇到的问题当然在交付价值的同时,有很多痛点是非常折磨人的:[*]权限分配:作为一个跨开发团队工作的团队,不但没有拥有比开发团队更多的权限,甚至连开发团队的一些权限都没有,比如不能向开发团队的代码库提交代码(修改基础设施代码需要这个权限),比如缺少Linux权限导致服务器底层问题没法直接修复,再比如 Jenkins 的问题追踪到了服务层需要维护Jenkins的团队支持,因为涉及到CI/CD的应用是由别的团队在管理。[*]沟通效率:为了解决一个bug,有时候要花上两周的时间发邮件,找关键人物,组织会议,跟不同的人解释五遍以上的上下文(技术细节的上下文是很繁琐的),最后解决问题的人还很有可能不是自己团队的(没有权限)。因为大家平时都很忙,而且建卡工作的方式让一部分人对团队请求帮助的问题不是很热心,这种情况在沟通的时候如果表现得情商不够高,对方就会要你发邮件给他们团队然后等 IM 建卡,规划到迭代里再说了,我遇到过一次这样的情况,最后还是通过社工手段拿下了这个关键人物,过程不可谓不曲折。[*]明确需求:Platform团队并不交付业务价值,因此没有BA(Business **yst业务分析师,通常扮演梳理需求的角色),建卡的事基本都由IM和Dev来做,虽然感觉上是合理的,但实施起来却遇到很多问题,究其根本就是对需求的定义和划分不够明确,导致最后挪卡的时候大家都说不准这张卡算不算完成了,只能用拍脑袋的方式来决定。[*]质量分析:同上,团队缺少QA(Quality Assurance,质量工程师,测试人员),Dev们都是自己做卡自己测,有时候会结对测试,但也会因为对需求理解不充分,或者说拆卡拆得有问题,导致一些卡完成得质量不够,直接影响受依赖的卡。举个例子,部署监控需要自动化脚本的两个模块支持,两个模块被分为两张卡,在做第一张卡的时候遇到了诸多问题,好不容易把代码提交到别人的版本库里了,在做第二张卡的时候却发现第一张卡代码里多写了一对引号,导致整个逻辑实现失败,这个时候再回过头来改之前的代码,又要重新解决之前遇到的各种问题(沟通、权限,PS:这个时候做第一张卡的人还下了项目),周期和浪费的工时是可想而知的。[*]人员轮岗:这是 IM 一直很头疼的一件事,Platform团队大量的时间花在给新来的团队成员输入上下文、同时又有成员离开团队要交接工作、尤其在沟通重要的工作中,成员的离开意味着需要新的人重新和干系人建立联系,再者,一些成员因为项目上的痛点,不是很有心思工作在团队的事务上,而是更关心自己过段时间会被分配到那个团队,如此种种都对团队的价值交付造成了很大的困扰。举一个例子,有一个端到端测试工具一直由Platform团队维护,从我加入Platform团队开始,这个测试工具就打算新增一个集成远程浏览器引擎的功能,这是一个非常有价值的功能,因为开发团队长期苦于浏览器版本支持过少,端到端测试不稳定;但是在实现过程中一直存在一个网络问题,这张卡先后被关闭、开启、标记完成、又重新开启,经历了大概五六个人的手,困扰我们的网络问题直到Platform团队解散,都没能解决。[*]关键角色管理:做了什么很重要,有时候让别人知道你做了什么比做了什么更重要。这一点在 Platform 团队体现的得尤为明显;在交付团队中,开发如果发现资源不足,需要和TL(Tech Lead 或是Team Lead,可以理解为项目组长)或者PM(Production Manager 产品经理)沟通,如果缺少合适的汇报对象,一方面在团队需要外部支持或更多资源(比如权限)的时候得不到及时的支持,另一方面意味着团队缺少了更高的视角来实时回顾自己做的事情是否是正确的,方向有没有走偏,或者是不是又在造别人造过的轮子。我在团队解散后的回顾会议中,IM还坚持认为我们团队被解散是因为没有一个强有力的领导在背后支持,这也从侧面反映了我们没有找到合适的汇报人,告诉他,我们在做什么,听他说,我们下一步可以做什么。分析问题背后的原因及可能的改进方案团队解散后经过一段时间的沉淀,我针对以上痛点与过往的成员一一交谈,了解了他们的想法,总结分析出了以下原因,以及可能的解决方案。原因1:团队方向不清晰 不同于交付业务价值的产品团队,Platform团队不对某一个具体的产品负责,也不直接产出业务价值,加上Platform团队对交付的价值缺乏有效的指标度量,造成了团队方向不清晰的状况。可能的改进方案:Platform 团队应该是属于架构师的一个机动团队,在团队方向不清晰的时候应该立即与利益相关者(Stakeholder)沟通,即与架构师取得联系,取得高视角的资源,最好能建立交付价值指标,比如Platform团队的目标是加快持续交付,提高交付质量,那就可视化开发团队发布周期、质量报告,让每个团队成员看到Platform团队交付价值的体现,从而明确团队方向。原因2:团队角色缺失在架构师不能全权参与团队工作的情况下(甚至Platform团队还可能没有IM),一帮Dev就很容易失去对团队整体的感知,每个Dev只关心自己手里的工作,迭代开始初期容易考虑不到全局影响、不能准确建卡,迭代进行时因为没有合适的汇报人因而跨团队交流困难,迭代结束时没有优质的回顾。 在Micromanagement Culture(微观管理文化)中有一个Alignment(校准)和Autonomy(自治)两个互斥的指标,我们使用这两个指标作为向量构成四个象限,如下图所示: 高校准、低自治的团队由领导决定做什么以及怎么做,团队只需要执行,这样会形成“领导说什么就是什么”的局面;[*] 而高校准且高自治的团队是由领导指出要解决的问题以及原因,然后由团队成员相互合作共同找到问题的解决方案;[*]低校准、低自治的团队则缺乏活力,只能循规蹈矩;[*]而高自治、低校准的团队成员可以做任何他们想做的事情,领导则很无助因为没有人关心真正需要解决的问题。在敏捷团队中,如果团队成员只剩下Dev,情形则很有可能变成图中左下象限(也有些许右下)的情况,要想达到右上象限的期望状态,需要提高自治,更多的是校准。可能的改进方案:在意识到这个问题的时候,团队需要一个关键人物出面充当领导者的角色,扮演这个角色的人必须关注团队交付价值、目标和方向,并且有强大的沟通能力让团队成员目标一致;和利益相关者加强沟通,保证团队方向不会跑偏。 高校准、低自治的团队由领导决定做什么以及怎么做,团队只需要执行,这样会形成“领导说什么就是什么”的局面;[*]而高校准且高自治的团队是由领导指出要解决的问题以及原因,然后由团队成员相互合作共同找到问题的解决方案;[*]低校准、低自治的团队则缺乏活力,只能循规蹈矩;[*]而高自治、低校准的团队成员可以做任何他们想做的事情,领导则很无助因为没有人关心真正需要解决的问题。在敏捷团队中,如果团队成员只剩下Dev,情形则很有可能变成图中左下象限(也有些许右下)的情况,要想达到右上象限的期望状态,需要提高自治,更多的是校准。可能的改进方案:在意识到这个问题的时候,团队需要一个关键人物出面充当领导者的角色,扮演这个角色的人必须关注团队交付价值、目标和方向,并且有强大的沟通能力让团队成员目标一致;和利益相关者加强沟通,保证团队方向不会跑偏。根本原因Platform团队成立初期被定义为一个立意高远(DevOps转型)的组织,但是在项目实施过程中变得越来越边缘化,其中有“人”的原因,有组织架构的原因,当然还有一些客观原因。但我突然意识到这背后有一个原因一直忽视了,那就是——我们在实践DevOps反模式。 国内近年来一直在对DevOps如何落地争论不休,DevOps提倡的是打破开发和运维的部门墙,将开发和运维(的能力)放在一个团队。然而国内大部分项目的现状是,开发不具备运维技能和意识,也不愿意做“背锅侠”(要求开发做运维一定程度上牺牲了开发的利益,比如亚马逊的开发每隔一周会被要求24小时On-call)。 因此一些公司选择了在项目中先成立一个 “DevOps团队” 作为过渡,再慢慢将CI/CD的理念和技能扩散到其他团队,但是这种方式稍不注意就会变成“换了个名字的Ops ”,因为工作内容相似,写脚本、做高可用,这些是传统运维也会做的事情,这种形式非常不利于团队思维的转变,“团队整体对最终交付物负责”才是DevOps的精要,而不是把团队按职责划分(只对流程负责)。 这样的要求无异是给项目成员增加了工作量和责任,对他们提出了更高的要求。然而很多职员不愿意无回报地多背负一些责任,比如说开发,谁不愿意每天写点代码一提交就早早回家,DevOps要求他们得看着新功能上线,确保无误之后才能离开;所以DevOps的推行在产品团队中是有阻力的,因此DevOps的成功不光需要团队内部努力,也需要得到高层支持并扫除障碍。 反思[*]尽早找到关键角色,并且管理好利益相关人。这一点在一个扁平化组织里往往是最容易被忽视的,在意识到要和 Stackholders(利益相关者)建立联系之前,Platform 团队走了很多弯路,也错失了很多机会。[*]让事情发生比如何发生更重要。应该说在这5个月的工作中,我认为最有价值的是最后两个迭代开始真正搜集来自应用团队的需求,开始在两地组织各个团队的 TL 开会搜集痛点和解决方案。作为 Platform 团队的一员,这件事其实我早就意识到会是非常有价值的,但始终没有去做,总是顾虑不知道怎么去开始、去推动,担心TL 们提出的问题不能得到真正解决。但是最后这件事终于发生了,才意识到真的是非常有价值,而且早该这么做了。我们是否还需要DevOps团队结合我自身的经历,“DevOps 团队”应该是一次有价值的试错,让我看到了这种方式的一些弊端,应用开发团队自身如果不具备产品思维,要由一个**的团队去影响它们是很难的,这种实践下的 DevOps 团队就像是披着 DevOps 外衣的 Ops 团队,不能产生理想的价值。 相比之下如果有一种自上而下的方式让开发团队基于已有业务基础之上去优化交付流程,并对每一个提交的最终价值负责,将产品思维真正植入到开发团队,从而达到全局优化的效果,这种做法才更符合真正的 DevOps 精神。线,确保无误之后才能离开;所以DevOps的推行在产品团队中是有阻力的,因此DevOps的成功不光需要团队内部努力,也需要得到高层支持并扫除障碍。
  • 提升软件开发者效率的10个提示
    本文转自以为电信软件开发云工程师的总结,希望能与大家一同分享这些可以极大提升效率的重要提示,从而增进你的整体输出。也许最重要的是,能够让你抽出时间做些别的事情。值得注意的是,下面这些提示既可以用在个人管理方面,也可以用在专业管理方面,这些原则本质上是一样的。1.绝不要将阅读邮件作为早上的第一件事请千万别将阅读邮件作为早上的第一件事。如果这么做了,那么你自然而然地就处于一种被动的状态之下,而不是你希望的那种积极、主动的状态。只在每天预先设定好的时间窗内查看和回复邮件,可以在午饭前,比如说12点到13点之间,然后在16点左右再看一次,因为这个时候你的能量可能处于下降的趋势,查看邮件并不会导致效率的降低。别担心,那些所谓的“紧急”邮件在绝大多数时候并没有那么紧急。2.如果可能就别去开会在企业环境下,会议是头号效率杀手。其实道理每个人都知道,只是有人不愿意承认罢了。Dave Barry曾说过“会议让人上瘾,导致人们过于放纵,很多公司与大型组织都是习惯性开会,否则有些人可能就无事可做了”。值得注意的是,会议会导致多人效率的同时下降。如果不是那种非参加不可的会议,那就别参加了。你可以说手头还有很多事情要做(也许事实就是如此),然后在会议后问一下参会的同事,了解一下重要的内容就行。如果真的有必要参加某个会议(这种情况其实并不多),那么请记住下面这些原则:[*]在下午效率下滑时开会。[*]一定要设定好要讨论的主题,别随意发散。[*]设定严格的会议结束时间,时间到了就立刻散会。[*]会议结束时一定要确定好清晰的下一步行动计划。3.别分心这个话题很大。在当今这个信息时代,导致我们分心的事情比比皆是,这些事情阻碍了我们正常地完成工作。我将分心划分为两类:一是我们自己造成的,二是别人造成的。首先说说第一种。看起来很奇怪吧,但实际情况却是我们自己导致自己效率下降,甚至有时都是无意识的。这种情况比比皆是:邮件、社交媒体的“重要”通知,在不同任务间频频切换,看到Hacker News或是Reddit上的有趣新闻等等。你应该创造这样一种工作环境,那就是在工作时没有任何东西能够令你分心。首先关掉所有通知,比如说手机上的短信、Facebook更新等等。接下来,退出邮件应用,如果开着的话,请确保禁用掉自动发送/接收选项。然后,不要访问任何不会提升你效率的网站。我们都是极客,我相信你应该知道如何做到这一点。你可以通过比较底层的方式来编辑机器的hosts文件,将facebook.com指向127.0.0.1,或是使用插件来临时禁用掉这些站点。我自己使用的是Blocksite插件。下面谈谈第二种。你可以说上面这些令你分心的情况是由其他人造成的,不过真实情况却是你自己造成的,因为没有人强迫你访问Twitter或是Facebook。第二种我称为“强迫”分心。这些情况是否出现在你身上呢?比如说,你收到经理发的一封邮件,然后他问你是否收到了,诸如此类。事实上,这种分心是比较难抵御的。有些建议,比如说戴上耳机(不过有时这样也不管用)、让来电进入语音邮箱,然后再去查看,或是在PC上放一张纸,写上“请勿打扰,编码中”等等。你要看看哪种情况比较适合你的工作环境,然后采取相应的行动。总的目标就是让工作能够连贯下去。4.前一晚准备好任务清单你应该在前一晚准备好一个第二天要完成的任务清单。我这里指的并不是那种巨大的清单,这样根本就没效果。相反,列出两三个重要任务即可,这应该是会对项目产生重要影响的任务。比如说:如果今天搞定这两个任务,那么我的效率就非常不错了。5.先做重要的事如前所述,邮件绝不应该是一天当中首先要处理的事情。那什么是首先要处理的呢?当然是清单中最重要的任务了。你应该识别出最重要的任务,然后坐下来专心解决,而不要再去考虑别的事情。理想情况下,你应该一气搞定,然后休息一会,再来做第二重要的任务。6.批处理并不是数据库才有的我相信很多人都应该很熟悉批量查询的概念。一言以蔽之,你将相似的数据库查询放在一起,然后在一个请求中发送出去,这样可以提升性能。你也可以在自己的任务中应用这条原则。也就是说,将某个任务的代价、各种开销最小化。邮件、电话以及任何重复性的工作都是批处理的最佳应用场景。7.自动化添加到效率工具箱中的另一个东西就是自动化。作为程序员,本质上我们生活在一个相当自动化的环境中,不过我曾看到不少开发者使用手工的方式来解决本可以轻松自动化完成的事情。人类的可靠性不如机器,特别是在面对那些无聊和不太重要的事情时。请尽可能自动化你所面对的任务。比如说通过一键的方式来执行完整的应用构建,使用一个脚本将应用部署到产品服务器上。严肃地说,请不要将你的精力浪费在机器能够更快、更可靠完成的事情上。8.调整工作与休息,实现效果最大化现在来谈谈如何创建良好的工作框架这个问题。我的建议是为工作分配特定的时间,同时为休息,或是娱乐分配特定的时间。比如说,你可以使用45分钟的时间进行持续、集中的工作,然后花15分钟休息一下,看看社交媒体更新情况,阅读一些文章等。在休息时就别再盯着屏幕看了。久坐是非常不好的习惯,适当地站起身,走一走。9.将事情记录下来将一切都记录下来。无论是新想法,还是新的做事方式,要知道,大脑有时是不可靠的,你需要将这一切记录下来才行。你可以将大脑看作是一个CPU,分配给它的东西就好比是在后台启动的进程。有时,进程会挂起,不能正常工作。将事情记录下来则会解放大脑,可以让其以更加优化的方式执行任务。10.利用心流,专心工作这是个圣杯,正是我们通过恰当地设计工作框架而要实现的东西,也是前面那些提示所要实现的终极目标。我敢肯定你经历过“心流”的状态,这指的是你的思维完全专注的一段时间,聚焦于特定的任务或是难题,甚至忘记了时间的流逝。头脑中除了编码,没有其他的东西存在。外部刺激也不会令你分心。你需要将自己置身于能够实现心流的状态下,尽量保持更长的时间,这将极大提升你的生产率,我敢肯定你会非常喜欢这种状态,为什么不让自己尝试一下进入这种状态呢?
  • [技术干货] 华为软件开发云新手训练营:项目管理
    视频贴视频时间长可能失效,可访问华为云社区视频专栏观看本视频:https://bbs.huaweicloud.com/videos/100748
  • [视频] 华为软件开发云功能介绍之编译构建
    本帖最后由 DevCloud 于 2017-9-22 16:13 编辑
  • [视频] 华为软件开发云功能介绍之部署管理
    本帖最后由 DevCloud 于 2017-9-22 16:13 编辑
  • [视频] 华为软件开发云优秀开发者分享
    本帖最后由 DevCloud 于 2017-9-22 16:13 编辑
  • [视频] 华为软件开发云功能介绍之项目管理
    本帖最后由 DevCloud 于 2017-9-22 16:12 编辑
  • [视频] 华为软件开发云功能介绍之测试管理
    本帖最后由 DevCloud 于 2017-9-22 16:12 编辑
  • [视频] 华为软件开发云新手训练营:代码检查
    本帖最后由 DevCloud 于 2017-9-22 16:12 编辑
总条数:132 到第
上滑加载中