欢迎一起探讨各自在前端开发中遇到的工程问题

[fouber]

恩，这个repos虽然命名是blog，一开始也定义为我的个人博客，但感觉光我一个人码字也挺空虚寂寞冷的，所以希望有在前端工程方面遇到问题，或者有所感悟，或者有所实践的同学，可以尽情在issues里开启话题来与大家分享交流，有个比较集中的地方讨论有关前端方面的工程问题也挺好的不是~~

[ciys]

工作5年了,一直处于公司需要什么研究什么的的状态,一直没仔细认真的去研究过某项东西,之前做的项目都是基于局域网的管理系统,现在准备做web项目,但是从来没设计过这方面所以有些不知所措,不知道该怎么做,后来通过网络了解了前端模块化的概念,也使用了seajs等,最近有开始接触fis打算想把这两个混合用,但是不知道怎么下手,不知道楼主有没有什么好意见

[nimoc]

@lucifercha
我来凑个热闹。

不建议将 seajs 与 fis 混合在一起用，建议用 webpack + fis3

seajs 后续衍生了 spm , spm 后续因为webpack， spm 停止维护了。

[ciys]

@nimojs 好的谢谢 我研究研究

[nimoc]

如何与 fis 的 map.json 结合构建一个基于 git 和 node 的前端静态资源服务器？

不了解 fis 的 map.json 的请点击此处

以前前端静态文件是与后端 server 一起发布的，现在有一个服务器可以用于做专门的静态资源服务器。

目前想法：

• 使用 github 做版本控制和 code review
• 静态资源服务器基于 node 和 nginx
• 使用 fis 作为前端工程核心，md5化所有静态资源文件（map.json 在后端 server 上）

---

我现在遇到 2个关键问题

1. 用哪种方式发布代码到静态资源服务器？

2. 基于map.json 后遇到问题如何做版本回滚?

   没配置过独立的前端静态资源服务器，希望各位能分享出自己团队的做法和给我一些建议。

[fouber]

@nimojs

可以新开issue。。。

关于代码发布

发布静态资源看你们自己的部署方案吧。一般是公司内撘一个ci系统，比如jenkins，然后在上面安装运维提供的部署脚本，然后配置gitlab（通常不用github，防止泄密）的webhook，一有提交就发请求到jenkins上，jenkins拉取代码，调用fis构建，然后把产出的代码通过运维脚本推送到测试或者生产环境。大致的流程是：

1. 内网搭建gitlab/svn
2. 内网搭建ci系统（jenkins）
3. 在ci系统所在机器上安装fis、运维推送脚本
4. 配置gitlab的webhook，一有提交就发请求给jenkins
5. jenkins中创建job，填写gitlab中的url，填写hook脚本

运行效果：

1. 开发人员提交代码，gitlab触发webhook，推送信息到jenkins
2. jenkins根据推送的信息执行对应的job
3. job中的脚本clone对应的分支，调用构建工具对代码进行构建
4. 使用运维脚本将构建完成的结果推送到测试/生产服务器。

上图中的SCRAT是我们基于FIS定制的自己的工具

总之效果就是【提交代码】→【自动部署】，【自动部署】包括了【构建】+【代码推送】

关于map.json回滚

其实每次发布，都可以把构建好的代码生成一份tar包存到代码库里，生产/测试/开发环境可以自由切换任意版本的包。服务端的包自然携带了map.json，切换哪个就代表了回滚哪个。静态资源不用回滚，丢在静态资源服务器就好了

[nimoc]

@fouber
在 fouber/blog 新开 issues 么？

---

感谢回复，目前我们没有运维人员。

考虑使用 githook master分支同步部署

本地 fis 构建 -> 提交构建后的代码 -> githook部署

版本回滚通过回滚后端中的 map.json 实现。

区别于 server 构建缺点应该是在 git 中会存在很多构建后的 md5后缀文件。

---

对于这些 jenkins 运维脚本 都完全不了解，公司也没有相关的运维人员。小型团队的前端开发人员想要构建一套代码发布系统应该通过哪些渠道和学习哪些知识可以做到这件事？

[nimoc]

这里的运维脚本包括中 fis 的构建代码么？

[nimoc]

或者使用另外一种手动发布的方案

前端生成环境使用git/svn，需要发布时使用 fis 的deploy-部署配置 和 fis-deploy-git 手动发布构建后的代码到前端静态资源服务器。

没有运维人员的情况下就做好版本控制和能快速控制版本回滚。

[fouber]

有一些低成本的做法，借助git：

1. 创建两个仓库（注意，是仓库，不是分支）：

   • release：包发布仓库，用于管理包和回滚
   • source：源代码仓库，用于开发

2. 在 source 仓库中准备一个 release.sh 脚本，大致的内容是：

   fis release -Duolmpd ./output           # fis构建到output目录
   cd output                               # 进入output目录
   pack_time=`date -d now +'%Y%m%d%H%M'`   # 构建时间
   pack_name=build-$pack_time              # 压缩包名称
   tar zcf ../$pack_name.tgz *             # 打一个压缩包，带时间戳的
   cd ..                                   # 回到上一级目录
   rm -rf output                           # 删除output
   
   git clone ``你的release仓库``            # 克隆release仓库
   cd release                              # 进入目录
   mv ../$pack_name.tgz .                  # 把之前打的tgz包贴过来
   git add -A && git commit -am "xxx"
   git push origin master                  # 提交

3. 在你的 release 仓库中准备一个 deploy.sh 脚本，你可以给它传参数，指定某个具体的tgz文件，这个sh脚本的功能就是解压缩对应的代码包，然后把内容推送到部署服务器上。

你的 source 仓库看起来内容是：

source
  ├─ components
  ├─ views
  ├─ server
  ├─ release.sh
  └─ fis-conf.js

你的 release 仓库的内容大概是：

release
  ├─ build-20150328143321.tgz
  ├─ build-20150410162404.tgz
  ├─ build-20150628203349.tgz
  ├─ ...
  └─ deploy.sh

要上线（或回滚）什么包，就在release仓库下执行：

./deploy.sh build-20150410162404.tgz

[jialezhang]

webpack+gulp,基本可以解决模块打包和上线的问题了 😄

[nimoc]

@fouber
关于 release source git 低成本方案。
回滚可以通过操作后端服务器中 map.json 控制，那么 ./deploy.sh build-20150410162404.tgz 的操作是否可以省去？

而 release 仓库直接就是正式环境 git

[fouber]

@jialezhang

webpack和gulp都只是构建工具，上线部署和包管理还需要额外的工作

[fouber]

@nimojs

release是保存各种历史发布包的仓库，你需要这个仓库以方便快速回滚啊，map.json只是资源表，回滚不仅仅回滚前端资源表，还有你的后端模板也可能需要一并回滚

[nimoc]

@fouber
明白了，原先我的想法是正式的静态资源服务器上的内容只增加不删除。所以想以 map.json 作为前端版本控制核心。