本地开发edx有许多坑，其中一个是open edx的环境搭建十分复杂，而且极其耗费cpu和内存资源。如果每个小伙伴都自行折腾一遍，真是一个不小的精力浪费。而且由于各自平台的不同，出现的错误五花八门，虽然采用vagrant可以部分解决，但vagrant本身又引来了各种蛋疼的问题。

就我个人而言，习惯分布式的协作，团队成员分布在全国各地，甚至国外，为了交流方便，常常围绕一个一致的中心，否则容易各说各的，这个中心包括源码远程仓库和一致的开发环境。

为了让每个人专注在自己的领域，通过分工来达到最大效率，团队中最好有一个全栈(其实就是万金油 囧)来协调大家。全栈未必熟悉具体细节，但对流程应该能整体把握，以便来黏合不同领域和分配任务，划清职责

#我们的开发环境 虽然我们的开发环境基于云，但思路是通用的，希望对你的团队也有用

目前我们的开发环境在青云上，按需付费。1核4G内存(swap)就足够了,ip按流量计费。价格很廉价

所有配置由技术负责人完成就行，任务量并不大。

###云端开发环境 云上存有一份干净的原生dogwood镜像，在此基础上定制出公司的开发基础版，假设代号为dogwood_base，该基础版包括一同通用的定制。

前后端的开发均从中衍生各自的版本。

###代码管理

  • 只谈论核心仓库：edx-platform
  • 在git服务器上，存有公司定制的open edx源码库，存为私有仓库
  • dogwood_base是基于named-release/Dogwood的分支
  • 团队每个成员均有自己的开发分支，命名为<NAME>/<FEATURE>,<NAME>为成员姓名,<FEATURE>为功能代号
  • 技术负责人负责将各个开发代码merge到dogwood_base，当然你也可以采用gitflow工作流

#后端开发 后端开发的同学，可能分布在网络各地

tmux可以让你们在一个同个shell会话里协作:参考使用 tmux 结对编程

采用组来做到协同会话

1
2
3

:::text
tmux new-session -s groupedsession
tmux new-session -t groupedsession -s mysession

####新人入职 只需要给他分发一个镜像就好啦，环境的搭配十分容易。团队内经验的传递也是个影响效率的关键因素，通过tmux，新老员工能容易地结对编程，经验的传递变得容易。使用qq和文档互动性是很低的，而高互动性能明显提高学习效率，tmux，你值得拥有

####为前端提供服务 前端同学一般对linux不怎么熟悉，后端同学最好能直接给他们一个一切就绪的环境，因为我自己在处理后端，所以给后端安排的任务会多些

  • 负责后端的同学，折腾好配置环境，可以用我的edx_tools,按照这篇教程为前端同学准备好环境：edx前端定制开发工作流,交付给前端的仅仅是个一切就绪的url
  • 将前端修改的文件拉取到themes目录，按照theme机制摆放定制文件，参考edx-platform/themes

####在云上开发xblock 相比于xblock-sdk，我更倾向于原生的环境，有了云的话，很容易将环境分发给xblock开发者

####特性开发（遇到风险） 在开发一些新特性时，有些特性可能会搞坏环境，当这种情况出现，云环境能很好帮到你，做个快照只要你不到一分钟的时间

#前端开发 由于云端是外网可访问的，后端同学可以帮助前端构建好所有的环境，所以前端可以专注在前端开发，不需要与环境和服务器打交道（open edx的环境对于后端同学来说头很头疼，实在不该把锅甩给前端，毕竟术业有专攻）

前端同学只需要打开浏览器，输入ip就得到一个干净的开发环境，所需要做的只是用Chrome Dev Tools或者firebug来直接调试scss代码

sass1.png

前端同学的工作流为：

  • 配置好chrome/firefox， 使其支持sass调试，参考Using source maps with Sass 3.3
  • 直接在chrome里调试,如下如 sas2
  • 由于在chrome里的修改只对当然会话有效，我们需要将修改保存到本地，使用git管理，每个修改旁边都应该有注释说明，注释格式为：// <NAME>:<MESSAGE> sas3