repository – 为开发人员创建有效的工作流程

前端之家收集整理的这篇文章主要介绍了repository – 为开发人员创建有效的工作流程前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我需要一些关于我们的工作流程与其他人相比的想法.我们有一个开发人员在我们的营销网站上工作,她知道如何编码和关于它(没有源代码控制经验,没有命令行……没有).过去,开发人员总是使用 Eclipse直接在服务器上编辑所有内容.这意味着,如果她捏造一些东西并保存它,它就可以被世人看到.

因此,在经历了数十次“不幸”后,我的任务是创建一个比仅仅编辑实时服务器上的文件更合适的新工作流程.这是我到目前为止所拥有的……

>具有营销存储库的Subversion服务器
>一个“生产”虚拟机,主要营销网站在我们说话时在网络上.
>“暂存”虚拟机,允许她在将任何更改上传到“生产”之前查看相同环境中的更改
>一个脚本,允许她将最新的SVN标记同步到这些服务器中的任何一个.

为了保持这两个服务器的完整性,我想制作第三个“SandBox”服务器.它是从“Staging”服务器复制的另一个VM.使用此服务器,她可以试验代码,尝试新事物,而不用担心使登台或生产服务器FUBAR.

当我提出这个计划的时候,我从多方那里得到了很多关于这为她创造了多少工作的抱怨和抱怨.流程将是:

编辑新分支中的代码>同步到SANDBox.重复直到满意.将更改合并到Trunk,从trunk创建新标记并同步到STAGING.做QA检查.如果一切正常,请同步到PRODUCTION. (我对这个过程的新想法非常开放)

正如可以期待那些从未在生活中使用过源代码控制并且习惯于编辑文件的人,推动ctrl s保存,然后刷新浏览器,这是一场噩梦.我很想找到一些中间立场,但如果我们要保持SandBox / Staging / Production的设置,我很难这样做.

什么对你们有用?

解决方法

你的计划基本上是合理的.

来源控制:

对开发人员的工作强制执行.通过各种方式,将该开发人员发送到培训或本地开发团队进行击败.说服你的共同老板说出需要. (如果必须,使用’恶意’或’留下一些东西’的场景,或简单的’网络服务器遭到黑客攻击和破坏’的情况.虽然我会推荐git用于任何新项目,托管在私人服务器上或付费的github帐户.ThinkLikeAGit,Roger Dudler’s “Git – The Simple Guide”和“Git for Ages 4 and Up(direct to video)都很棒.

我更喜欢Master是一个主要的开发分支,一个要部署用于测试的Staging Branch,以及一个Production分支(或Staging分支上的Tags,在已部署的提交上有版本号).我也喜欢分支功能的想法.询问100位开发人员他们喜欢他们的源代码控制,你会得到大约65个答案……

我非常不喜欢并建议不要将Master作为“生产”部门.一个新手的错误(每个人都这么做)就是犯了错误的分支.不要让Production成为默认分支.

开发服务器:

是的,开发狂的地方.做你想做的;这是你的家,沙箱,无论如何.开发应该在本地机器上进行,但这是一个看似生产的环境,但是变得疯狂的灵活性.建议在基本状态下(以及每当Prod更新时)拍摄快照的VM.

登台服务器:

一旦开发人员对她的代码感到满意,它就会部署到Staging Server.这是一个完全匹配生产的服务器,URL除外. (她的代码应该使用相对路径,而不是网站的实际名称.)

这是踢球者:一旦她对网站准备好生产感到满意,她就会停下来.她没有部署到Prod(尚未).现在正在发生一个未知到未知的QA流程.有人注意到错误(并且至少能够理解这个新代码应该做什么)的人会在Staging中查看该网站. (你,创造者,对你自己的许多错误视而不见,使你无法验证自己的工作.)他们测试网站,确保正在修复的问题,以及没有任何新问题被破坏.

我不能强调这一点:开发人员不做QA!在将其传递给QA之前,她应该确保她的网站没有任何明显的破损,但她不批准生产. (首先,她表现出对最佳实践缺乏了解,并且错误表明存在最佳实践是出于正当理由.)

做QA的人的职业声誉受到威胁;如果一个错误被推送到Prod,那是他们的批准才能实现.

如果QA发现错误,则会向开发人员确定是否存在错误.这个过程重新开始,完成QA审查和签字.

就个人而言,我是Devs做自己部署的粉丝.他们得到即时反馈,知道任务已经完成,并且不让其他人进行部署,如果出现问题,他们会感受到更大的主人翁意识. (说“它适用于我的机器”应该是一种死罪.)

最重要的部分是repo中的内容被部署.没有“一次性”牛仔编码的变化.

生产:

一旦QA签收发生,代码最终可以推送到Prod.这取决于您和您的组织进行部署;它可以是编码员,也可以是QA人.如果部署未完全执行,则会返回给开发人员.

结论:

事情的进展现在显然不起作用.推动制定类似强制性公司政策的内容(当然,如果您同意这一点),并按照其遵守条件制定就业条件.它可能会为您的可怜开发人员制定更多步骤,但对于公司而言,它的工作量较少,特别是在出现错误时.更不用说安全网了解生产网络服务器之外的已知良好状态代码.

可选的奖励积分

我不知道你为部署做了什么,但它们应该是一步或无步.

One-Step Deploy的一个示例是您在Prod服务器上运行的脚本(也应该是Staging服务器,也是Devl),它从您的repo中下拉相应的Branch并重新启动所需的Web服务.

No-Step Deploy的一个示例是一个cron,它监视相应的Branch并在更新Branch时自动更新代码.

猜你在找的HTML相关文章