Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

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

Closed
fouber opened this issue Jun 25, 2015 · 204 comments
Closed

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

fouber opened this issue Jun 25, 2015 · 204 comments
Labels
杂谈

Comments

@fouber
Copy link
Owner

fouber commented Jun 25, 2015

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

ciys commented Jun 26, 2015

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

@nimoc
Copy link

nimoc commented Jun 26, 2015 •
edited
Loading

@lucifercha
我来凑个热闹。

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

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

@ciys
Copy link

ciys commented Jun 26, 2015

@nimojs 好的谢谢 我研究研究

@nimoc
Copy link

nimoc commented Jun 28, 2015

如何与 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
Copy link
Owner Author

fouber commented Jun 28, 2015

@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. 使用运维脚本将构建完成的结果推送到测试/生产服务器。

image

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

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

关于map.json回滚

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

@nimoc
Copy link

nimoc commented Jun 28, 2015

@fouber
在 fouber/blog 新开 issues 么？

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

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

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

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

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

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

@nimoc
Copy link

nimoc commented Jun 28, 2015

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

@nimoc
Copy link

nimoc commented Jun 28, 2015

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

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

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

@fouber
Copy link
Owner Author

fouber commented Jun 28, 2015

有一些低成本的做法，借助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
Copy link

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

@nimoc
Copy link

nimoc commented Jun 28, 2015

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

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

@fouber
Copy link
Owner Author

fouber commented Jun 28, 2015

@jialezhang

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

@fouber
Copy link
Owner Author

fouber commented Jun 28, 2015

@nimojs

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

@nimoc
Copy link

nimoc commented Jun 28, 2015

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

@fouber
Copy link
Owner Author

fouber commented Jun 28, 2015

@nimojs 静态资源服务器上的内容可以只增不减，但你的服务端模板以及模板所使用的map.json还是需要整体部署或回滚，只改map.json可能会导致模板与静态资源内容不匹配而报错

@nimoc
Copy link

nimoc commented Jun 28, 2015

@fouber
那么构建后的前端静态资源文件是必须做版本控制以方便回滚？
构建后的前端静态资源文件可以通过 *.tgz 的方式备份？

看来还是 有一些低成本的做法，借助git 方式最合适。

按照这个方法，每次版本更新需要开发人员在 release 仓库运行 ./deploy.sh build-20150410162404.tgz ?

@fouber
Copy link
Owner Author

fouber commented Jun 28, 2015

@nimojs

如果你的静态资源服务器和模板服务器是不同的webserver，比如静态资源要推送到七牛上，那么你可以：

  1. 修改source仓库的release.sh执行过程：
    1. fis release
    2. 将静态资源推送到静态资源服务器
    3. 只把模板(或页面)和map.json打包到tgz文件中
  2. 每次发布或回滚，只需要开人员去release仓库执行deploy.sh即可，切换的都是模板和配套的map.json，静态资源始终扔在静态资源服务器

@nimoc
Copy link

nimoc commented Jun 28, 2015

@fouber
感谢
我们 php server和 static server 是分开的。

那么最终可以采用：发布到测试环境时提交后端模板、map.json 、执行 deploy.sh 发布静态资源到static server。

测试环境发布到正式环境由后端解决，而前端资源在发布测试机时就已经部署好了。

@jialezhang
Copy link

@fouber 感谢,我这里现在还没有包管理的需求(主要是太小了....),暂时webpack和gulp直接可以解决上线部署的东西,不过看了这些开阔了视野了!!!

@ciys
Copy link

ciys commented Jun 29, 2015

楼上的各位讲的都太高大上 看的云里雾里的

@fouber
Copy link
Owner Author

fouber commented Jun 29, 2015

@jialezhang
上线部署是指项目构建之后，需要把构建好的代码上传到服务器上，上传的过程有些团队用的是ftp，有些用的是rsync，这两种方式有对应的gulp插件，个人开发可以直接上传。不过对于团队要长久维护一个大一些的项目，上线/回滚是很常见的运维操作，每次部署的历史版本都应该保留，在新版本有问题的时候方便立刻恢复之前的版本，在服务器挂掉之后方便立刻部署到其他机器上。

@jialezhang
Copy link

多谢 @fouber 大神讲解！这些东西估计要等到有好几个人一起开发才需要了

@nimoc
Copy link

nimoc commented Jun 30, 2015

@fouber
重新整理了下思路，请帮忙看下如下方案是否靠谱：

（以下源码指的是未处理的 less sass 等文件）

  1. 使用 git 管理源码。分支 PR 到 master (master 中只有源码)
  2. 当 master 有修改后 webhook 推送到 node server
  3. node server 接受文件，在 server 中对源码执行 fis 构建
  4. 将构建后的代码发布到前端静态资源服务器

这样源码在 git中做版本控制。需要回滚就回滚 map.json。（其实就是 fouber 给出的第一个方案中去掉 jenkins 的版本）。开发人员只关心2个步骤 【本地编码看效果】 -> 【GIT RP 到 master】

但是 在 server 运行 fis 构建后得到的 map.json 如何发布到后端服务器我不知道怎么做合适。

目前想出2种做法：

  1. 当构建完成后像后端 server 提供一个接口发送 map.json 文件？
  2. 当构建完成后在 server 中将 map.json commnit 到一个单独的 git 中，这个单独git 的 webhook 触发后端脚本将 map.json 部署在后端服务器中？

@fouber
Copy link
Owner Author

fouber commented Jun 30, 2015

@nimojs
你没有使用后端模板吗？如果使用了，每次回滚map.json也要回滚模板的。

关于map.json推送服务器的问题，可以考虑用rsync，建立两台机器的信任关系，然后rsync推送

@nimoc
Copy link

nimoc commented Jul 1, 2015

@fouber
恩，使用了后端模板。版本回滚回滚所有后端代码和 map.json ，我将 map.json 理解为前端资源在后端的集合。

@Jokcy
Copy link

Jokcy commented Jul 1, 2015

@jialezhang
能交流一下你们webpack+gulp的工作方式吗？

@jialezhang
Copy link

@Jokcy
webpack：管理JS之间的依赖，（写React的时候很爽 hot-loader）; 会用ES6，webpack上babel。
gulp: SCSS预处理（之前会处理coffee），后期静态资源链接替换(gulp-rev)。
当然webpack的功能远不止如此.....我只是用了冰山一角

@feifeipan
Copy link

有没有介绍FIS的灰度发布相关的内容

我理解下来，灰度发布可以通过类似于<%require_js("core:core.js")%>这样的require_js方法来控制读取不同版本的文件。同时，获取mapjson的时候也需要返回不同版本才行。想法不太成熟。

@nimoc
Copy link

nimoc commented Jul 9, 2015

有没有介绍FIS的灰度发布相关的内容

@feifeipan
#6

@kursk-ye
Copy link

kursk-ye commented Nov 27, 2018 via email

@hjaiim
Copy link

hjaiim commented Nov 27, 2018 via email

@kursk-ye
Copy link

kursk-ye commented Nov 27, 2018 via email

@sankyutang
Copy link

@kursk-ye 既然前端他们都说实现不了，就可以优化了，换一波人。
设计稿 => 前端组件，输出的组件肯定是固定UI的，估计满足不了客户需求。

@fouber
Copy link
Owner Author

fouber commented Nov 27, 2018

未来的前端界面，很有可能都是由AI生成的。对于很多『用完即弃』的活动专题页，或许都应该交给机器和算法生成，把前端工程师从重复劳动中解脱出来。

前端工程化开发→前端可视化开发→前端AI辅助开发。

@chen-Aaron
Copy link

chen-Aaron commented Nov 27, 2018 via email

@OliverHzz
Copy link

对于合理拆分组件的理解不足 请问有木有相关的资料可以阅读？谢谢

@zuoez02
Copy link

zuoez02 commented Nov 27, 2018

@chen-Aaron 设计时就应该考虑响应式啊，要么设计师考虑，要么前端自己设计，不过前端自己设计的话界面设计或者产品未必能满意。推给设计去做吧，也不用太多，考虑好你的用户的可能的设备范围，分好分辨率范围让他/她考虑。比如如果你做个B端的后台管理，估计不用考虑手机那种情况了，又或者专门做大屏展示，就专门设计指定分辨率的都差不多了。
划分的话，参考bootstrap也可以的，分四五档

@lian8306
Copy link

lian8306 commented Nov 27, 2018 •
edited
Loading

首先一个问题是设计不可能每个分辨率都设计，其次只靠前端也没法实现所有分辨率情况。办法：设计几版界面变动比较大的情况，其他响应式自己搞.
@chen-Aaron

@luke93h
Copy link

luke93h commented Dec 9, 2018

未来的前端界面，很有可能都是由AI生成的。对于很多『用完即弃』的活动专题页，或许都应该交给机器和算法生成，把前端工程师从重复劳动中解脱出来。

前端工程化开发→前端可视化开发→前端AI辅助开发。

AI只是工具，而且AI必须满足受人控制，相信那时，前端会变得更有趣，更高级

@myzhibie
Copy link

有没有微前端的好的实现方案？现在公司由于各个前端应用都独立代码库，发布，部署，但是他们之间又有各种联系，希望在UI层面运行时将他们集成起来，一个很明显的例子就是页面上的header是由公共团队开发的，我的想法是将header的静态资源放到CDN上，各个应用通过网络加载header，现在希望各个应用不进行部署发版本就能够获得最新的header，那么这个版本怎么控制，还有缓存怎么控制？如何实现不发版本能够更新页面上对CDN上静态资源的依赖？

@daolou
Copy link

daolou commented May 25, 2019

有没有微前端的好的实现方案？现在公司由于各个前端应用都独立代码库，发布，部署，但是他们之间又有各种联系，希望在UI层面运行时将他们集成起来，一个很明显的例子就是页面上的header是由公共团队开发的，我的想法是将header的静态资源放到CDN上，各个应用通过网络加载header，现在希望各个应用不进行部署发版本就能够获得最新的header，那么这个版本怎么控制，还有缓存怎么控制？如何实现不发版本能够更新页面上对CDN上静态资源的依赖？

https://medium.com/javascript-in-plain-english/create-micro-frontends-using-web-components-with-support-for-angular-and-react-2d6db18f557a?mkt_tok=eyJpIjoiTkdZNFlXSm1abUpoTkRJdyIsInQiOiI3TWZ4U0lQaEVyVW9ZVzdqaUpub2NlRGI1UEJLajlGTk4zMytCRittbDA5STh4bDNtVE9TckRPRUgwa2xBSHRXTUxBYSs5Z2xBdllWRkFxMHdNdzVYQzZ1Q1ZjeFJGMndkQlpZdEkwRXNkOElnOVkreDg2emJ1VGpOXC9YNDluR2sifQ%3D%3D

https://web.dev/hands-on-portals

@xmter

This comment has been minimized.

Sign in to view
@tjuking

This comment has been minimized.

Sign in to view
@7greenfrog7

This comment has been minimized.

Sign in to view
@liucan233

This comment has been minimized.

Sign in to view
@1073567594

This comment has been minimized.

Sign in to view
@JeffCP9527

This comment has been minimized.

Sign in to view
@imondo

This comment has been minimized.

Sign in to view
@staxing

This comment has been minimized.

Sign in to view
@ljwlee

This comment has been minimized.

Sign in to view
@FairyYang

This comment has been minimized.

Sign in to view
@tachibanakaori

This comment has been minimized.

Sign in to view
@weixue1014

This comment has been minimized.

Sign in to view
@liyueS777

This comment has been minimized.

Sign in to view
@CarolSum

This comment has been minimized.

Sign in to view
@feikalieluofa

This comment has been minimized.

Sign in to view
@heihuahe

This comment has been minimized.

Sign in to view
@fouber fouber closed this as completed Dec 27, 2021
Repository owner locked as spam and limited conversation to collaborators Dec 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
杂谈
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests