对于刚入行或应届生的前端同学来说，是不是还没有捋清楚一个项目有哪些版本或者说哪些环境呢?
一般来说，一个成熟且严谨的项目有哪些环境（或者说版本）：开发环境、测试环境、预发布环境、正式环境
接下来，我就给大家聊一聊每个环境的作用，以及为什么要设置这么多的环境
-
开发环境：进入公司将项目代码（远程分支，一般命名为"origin-master"），克隆到本地,这时你的本地仓库会生成一个和远程origin-master代码一样的分支，一般命名为master。基于master拉取本次需求的开发环境，可以命名为iteartor,然后将iteartor运行起来(一般通过终端命令行npm startXXX或者npm run startxxx），在浏览器运行起来，这个环境就是本地的开发环境，平时的需求任务都是先通过开发环境开发。注：在这个环境的项目只有自己的这台电脑能访问。
-
测试环境：当需求任务开发完成后，先自测一边，看看有没有什么bug，自测完成后，就可以将master分支的代码提交（push），提交完成后，打包代码，然后发布镜像，镜像发布完成后，项目就处于测试环境中（也就是测试环境更新了你开发的需求代码，别人才能看到你的需求开发效果），然后自测一遍（因为环境不同可能会导致出现bug），自测完成后就可以转测了，接下来的工作就是“可爱的”测试同学给你提bug了...（呜呜呜~）
-
预发布环境：预发布环境是线上的正式环境的最后一道检验环境，所以为了避免正式环境出现bug，设置预发布环境还是很有必要的（从饼干的小公司工作经历来看，还是有很多小公司不设置预发布环境的...，所以大公司的风控做的还是很科学严谨的）。当改完“可爱的”测试同学提出的bug之后，验证好了，就可以等待PM同学发布上预发布环境的通知了。预发布环境如何发布呢？
3.1 一般设置了预发布环境的项目，都会在远程的代码仓库里创建一个预发布环境的代码分支（命名：origin-release，这个origin-release是基于origin-master创建的），我们先拉取（pull）origin-release到本地，生成一个本地的release分支，将本地的master分支合并到release分支，再将release推送到origin-release，然后打包release代码，发布release镜像，这样预发布环境就发布好了。预发布环境只有内部人员才能访问体验。 3.2 预发布环境发布好了之后，同理再次自测一遍，然后交给测试同学测试，一般这个阶段了不太会出现bug，如果测试同学提了bug，那就在release分支上修改代码，改好之后push到origin-release，然后再进行代码打包，发布预发布环境。
-
正式环境：所有人员都可以访问以及体验的环境。就比如“百度”，大家都可以体验它的功能，此时它就是处于正式环境。
最后附上一张图方便“文字瞌睡者”
PS: 个人觉得程序员不仅仅要会写代码，其实自测自己的需求也是有必要的，尽量充分自测，不要把测试的工作全部都甩给测试同学，到时我们“可爱的”测试同学可是会疯狂的给你提bug...哈哈哈哈哈哈（饼干也是对他们提的bug敢怒不敢言）建议找个没人的地方 开发和测试好好Battle一下~~~
版权申明：由于文章都是小弟的工作经验总结，纯纯的脑力劳动成果和自我知识产权，所以：
1.博客中的文章，版权归原作者 # 前端Biscuits 所有；
2.未经原作者允许不得转载本文内容，否则将视为侵权；
3.转载或者引用本文内容请注明来源及原作者；
4.对于不遵守此声明或者其他违法使用本文内容者，本人依法保留追究权等。
只是希望大家在转载文章时，能够有版权意识。先联系原作者征得转载授权（其实这种事儿，我很好说话的，评论里或者私信跟我说一下，我一般都是会同意的），并且注明文章原始出处和原作者。
