系列文章：
为什么会有这篇文章
最近在团队里做组件库和项目模板的建设，为了配合建设和梳理工作流程也重新开发了脚手架。
这期间对脚手架重新梳理，记录下来和大家分享，欢迎勘误和指教。
这会是个系列分享，我将会分章节讲解我对脚手架的理解和现实过程。
我们为什么需要脚手架
现在脚手架是前端的标配工具、主要有以下几个原因：
- 前端项目越来越复杂、大量的配置管理和维护这些配置的成本很高、繁琐又重复的工作、价值低、需要工具化自动化；
- 我们需要进行项目目录结构、规划化配置和开发约束、保证夸团队甚至夸中心的项目标准统一；
- 规范流程、涉及创建项目、开发到发布上线的整个流程的管理需要工具进行标准化管理；
现在市面上脚手架都解决什么问题
现在开源框架都有提供自己的脚手架、如：vue-cli。
它们主要解决初始化项目时候配置繁琐的问题、可以用交互命令面板或者web界面的方式帮助你快速搭建项目。
但是在项目开发和技术管理过程中，一个团队会用到多套项目模板，但是同一领域或者技术栈的模板会采用同一个，用以规范目录结构，工程化配置，编码风格，通用工具和项目配置。
所以自建项目模板并不需要像vue-cli那么精细到项目的配置，vue-cli已经实现的功能我们不需要再重复开发，而是中心放到打通创建项目的全流程，将创建项目和发布项目全自动化。
我们准备实现一个什么样的脚手架
我们希望脚手架承担起前端全项目周期内命令行工具全部支撑工作。
发布流程演示：
V1.0支持以下：
项目初始化
我们将模版和脚手架进行了解耦、模板单独进行管理、我们采用npm包的方式进行模板管理、我们希望实现以下功能：
- 支持多类型的项目模板的管理，包括版本管理、因此我们选择了npm方式；
- 脚手架只需要负责进行项目初始化的操作；
- 支持测试打包脚本的初始化、我们用的jenkins；
- 自动配置测试环境、包括测试域名配置以及nginx脚本的自动生成和应用；
执行完初始化脚本后，包括标准化的项目、打包脚本以及测试环境都生成并设置完成、可以直接进行开发。
后面会分章节重点进行分析和讲解。
自动git合并以及分支管理
团队采用 git flow标准管理流程、我们希望除非遇到冲突、这个合并流程可以通过工具自动完成，最大程度降低重复的工作。
远程部署
支持接入jenkins或者ssh进行远程的打包和部署。
也可以扩展对接运维的持续集成工具、或者云平台的API进行部署。
其他命令行工具支持
其他团队定制命令行工具支撑。
