dev_flow 0.0.4

Sign up to get free protection for your applications and to get access to all the features.
data/README.md ADDED
@@ -0,0 +1,200 @@
1
+ DevFlow: ROADMAP/git based develop flow control
2
+ ===================================================
3
+
4
+ WARNING: Pre-alpha implementation for internal use only.
5
+
6
+ Pre-Requirement
7
+ -----------------
8
+
9
+ - A Bash command line console (cygwin is supported)
10
+ - A workable git installation and `git` command in the path
11
+ - Ruby 1.9.x
12
+
13
+ Install
14
+ -----------
15
+
16
+ $ [sudo] gem install dev_flow
17
+
18
+ Work Flow
19
+ -------------
20
+
21
+ Under you development working directory:
22
+
23
+ 1. Write a `ROADMAP` file in a specified format
24
+ 2. (Optional) create `members.yml` file define known developers
25
+ 2. Run `dw` command
26
+
27
+ Sub-commands for typical work flow jobs are:
28
+
29
+ $ dw [info] # show task information
30
+
31
+ $ dw progress 80 # mark the task as completed at 80 percent
32
+ $ dw pg 80 # same as progress
33
+
34
+ $ dw complete # mark that the implemention is completed
35
+
36
+ $ dw close # this command is for project leader only, it will close the current task,
37
+ # merge it into `develop` trunk and delete the git branch both
38
+ # locally and remotely.
39
+
40
+ $ dw release # like close but for release branch only.
41
+ # the change will be merged into both `develop` and `master` branch.
42
+
43
+ More commands may plug in later.
44
+
45
+ ROADMAP File Format
46
+ --------------------
47
+
48
+ The default task control file is `ROADMAP`, unless you specify an other file using
49
+
50
+ $ dw --roadmap OTHER_FILE
51
+
52
+ See more options by issue
53
+
54
+ $ dw -h
55
+
56
+ or
57
+
58
+ $ dw --help
59
+
60
+ ### Information Header
61
+
62
+ Contents between two
63
+
64
+ % ---
65
+
66
+ (with a head `%` and at least 3 dashes) lines and before any definition of task will be
67
+ treated as information header. Which should be in YAML format and should at least contains
68
+ `title`, `leader`, and `team`, like:
69
+
70
+ % ---
71
+ title: A Sample Project
72
+ status: producing
73
+ members:
74
+ qsh: [Qin Shihuang, 'qsh@qinchao.com']
75
+ leader: sunyr
76
+ team: [huangw xuyc]
77
+ year: 2013
78
+ % ---
79
+
80
+ If you define `year` in the header, you can write date in `mm/dd` format instead
81
+ of `yyyy/mm/dd`. Usually you should define developers in a separate `members.yml` file,
82
+ but you can define extra members in the header area too (usually for who only join to
83
+ one or few projects).
84
+
85
+ ### Team and Leader
86
+
87
+ Leader has a higher priority than team members, only leader can edit roadmap,
88
+ close a task branch, and make a release, etc.
89
+
90
+ If you also defines `supervisor`, `moderator`, they can update the roadmap too,
91
+ but can not close or release a branch.
92
+
93
+ IMPORTANT: those kind of permission is just introduced for avoid miss operation,
94
+ NOT intended as a security mechanism. You still needs setup permissions on your
95
+ remote git server if security is a concern.
96
+
97
+ Generally you are encouraged to use short names in team members to save typings,
98
+ by define a `members.yml` file in the following format:
99
+
100
+ members:
101
+ short_name: [Display Name, 'email@address.com']
102
+
103
+ This is also a way to avoid typos in ROADMAP definitions.
104
+
105
+ ### The Task Tree
106
+
107
+ Every line start with a `[+]` (or `[++]`, `[+++]` ...) will be treated as a task definition.
108
+
109
+ A typical task definition line should following the format:
110
+
111
+ [+] branch_name: taskname date/to/start[-date/to/stop] @resource[;resource] [-> dependent_on;dependent_on]
112
+
113
+ - `[+]` one or more + in bracket is the indicator of task definition,
114
+ one + represent a 1st degree (level) task, ++ represent a second degree task, ....
115
+ Task degree with smaller number may contains several tasks with higher degree number.
116
+
117
+ - `branch_name` must contains only a-z, 0-9, dot and underscore, which is used as git branch name,
118
+ and also serves as a id for that task within the same ROADMAP file.
119
+
120
+ - `taskname` could use any characters provide not contains 'date like' parts (see the next description).
121
+
122
+ - `date/to/start` should in format 2013/03/03 or 03/03 if you defined `year` in the
123
+ header (so you can specify only the `mm/dd` part). Use `mm/dd-mm/dd` (`yyyy/mm/dd-yyyy/mm/dd`)
124
+ to specify a period.
125
+
126
+ If the task duration is within one day, date/to/stop part can be omitted.
127
+
128
+ - `@resource`: resource should correspond to leader or one of the team member.
129
+ If the task need more than one resources use ; to separate them.
130
+
131
+ - If the task depends on other task, puts their id after `->`.
132
+
133
+ ### Git Branching Models
134
+
135
+ - `master`, `develop`, `staging` and `production` branches are **trunks**. Code implementation
136
+ and modification should be done in non-trunk branches and merged into trunks according the following roles.
137
+
138
+ - The `master` trunk is a production ready branch, `develop` is the **integration** branch
139
+ that contains latest code of completed feature that passed all integration test.
140
+
141
+ - Development branches (**task branch**) should stem from `develop` often, and merged
142
+ back into `develop` trunk as soon as the implementation complete and passed all unit and
143
+ integration tests.
144
+
145
+ - Release branches is purely for code review, test and necessary bug fix, after pass all of that,
146
+ they will be merged into both `develop` and `master` trunk, and a `release-xxx` tag will be attached.
147
+
148
+ ### Semantic Versioning and Special Tasks
149
+
150
+ Tasks with branch name starts with `release_`, `hotfix_` ...
151
+ will affect the version number.
152
+
153
+ You use `release_` branch to manually manage major and minor versioning,
154
+ e.g. `release_v0.1` will create a tag `version-0.1`, and hotfix branches
155
+ will add-up fix numbers after it such as: `version-0.1.28`. All those
156
+ branches will merged into `master` trunk.
157
+
158
+ `milestone_` is a special type of task that corresponding to important event
159
+ in the development flow (for example event for team code review,
160
+ customer acceptance review, etc.), but do not affect version numbers, so do other tasks.
161
+
162
+ Sometimes you may want to use 'prepare releases' such as `release_v0.1a`, `release_v0.1b`,
163
+ avoid sandwich tasks between prepare releases and releases.
164
+
165
+ Local Configuration
166
+ ---------------------
167
+
168
+ Default is stored in `.dev_flow` file and will be set to `git`'s ignore list (`.gitignore`)
169
+ (so these settings only affect your local working directory).
170
+
171
+ Without this file `dw` will go into the initialization mode (by asking you some questions).
172
+
173
+ You can use `--local-config FILE` to store those information in an other file name.
174
+
175
+ `.dev_flow` is also in yaml format and the most important key are `whoami` and `git_remote`,
176
+ `whoami` specifies who is currently working on the local working directory,
177
+ and `git_remote` defines witch git remote server to use (default is `origin`).
178
+ With out `git_remote` the `dw` command will not try to communicate to remote git server.
179
+
180
+ Command Details
181
+ -------------------
182
+
183
+ - `dw init` default command if no `.dev_flow` file found.
184
+
185
+ - `dw [info]` or `dw` without command will list the tasks and if the working directory
186
+ is clean, let user chose to switch to working for known tasks.
187
+
188
+ - `dw progress 0-98` set task progress. `dw pg` is an alias of `dw progress`. You are
189
+ encouraged to frequently use this command to store you changes to remote servers (typically
190
+ several times a day).
191
+
192
+ - `dw complete` set task progress to 99 (complete a task), urge the leader to review/test and
193
+ close it.
194
+
195
+ - `dw close`/`dw release` close the task by the leader, or release it (to master trunk).
196
+
197
+ - `dw update-roadmap` or `dw ur` used for update the roadmap (should only be used on `devleop` trunk).
198
+
199
+ - `dw cleanup` will delete local branches corresponding completed tasks (TODO).
200
+
data/ROADMAP ADDED
@@ -0,0 +1,15 @@
1
+ ROADMAP for dev_flow Development
2
+ ==================================
3
+
4
+ % -----
5
+ title: dev_flow development tools
6
+ status: producing
7
+ members:
8
+ huangw: [Huang Wei, "huangw@pe-po.com"]
9
+ leader: huangw
10
+ year: 2013
11
+ % -----
12
+
13
+ [+] release_v0.3: with version number handling 03/25 @huangw:03/25
14
+ [+] hotfix_taginfo: put tag situation on info screen 03/25 @huangw:03/25
15
+ [+] release_v0.4: with cleanup closed local task branches 03/25 @huangw:03/25
data/Rakefile ADDED
@@ -0,0 +1,3 @@
1
+ require 'rspec/core/rake_task'
2
+ RSpec::Core::RakeTask.new('spec')
3
+
data/bin/dw ADDED
@@ -0,0 +1,82 @@
1
+ #!/usr/bin/env ruby
2
+ # vim: syn=ruby
3
+
4
+ $: << 'lib'
5
+
6
+ require "optparse"
7
+ require "term/ansicolor"
8
+ class String; include Term::ANSIColor end
9
+ require "dev_flow"
10
+
11
+ options = {}
12
+
13
+ optparse = OptionParser.new do |opts|
14
+ opts.banner = "Usage: dw [options] [command]"
15
+
16
+ options[:roadmap] = 'ROADMAP' # the roadmap file
17
+ opts.on('-r ROADMAP_FILE', '--roadmap ROADMAP_FILE', 'use an other roadmap file') do |roadmap|
18
+ options[:roadmap] = roadmap
19
+ end
20
+
21
+ options[:local_config] = '.dev_flow'
22
+ opts.on('-l LOCAL_CONFIG', '--local-config LOCAL_CONFIG', 'use an other local configuration file') do |lc|
23
+ options[:local_config] = lc
24
+ end
25
+
26
+ options[:members_file] = 'members.yml'
27
+ opts.on('-m MEMBERS_FILE', '--members_file MEMBERS_FILE', 'use an other members file') do |mf|
28
+ options[:members_file] = mf
29
+ raise "the specified members file #{mf} is not exists." unless File.exists? mf
30
+ end
31
+
32
+ opts.on('-i', '--filter-tasks', 'show only tasks assigned to me') do
33
+ options[:filter_tasks] = true
34
+ end
35
+
36
+ opts.on('-o', '--offline', 'do not use remote git server') do
37
+ options[:offline] = true
38
+ end
39
+
40
+ opts.on('-v', '--verbose', 'print more messages') do
41
+ options[:verbose] = true
42
+ end
43
+
44
+ opts.on_tail('-h', '--help', 'Display this screen') do
45
+ puts opts
46
+ exit
47
+ end
48
+ end
49
+
50
+ optparse.parse!(ARGV)
51
+
52
+ # determine the command
53
+ command = ARGV[0] || 'info'
54
+ cmd_alias = {'pg' => 'progress', 'update-roadmap' => 'ur', 'clean' => 'cleanup'}
55
+ command = cmd_alias[command] if cmd_alias[command]
56
+
57
+ if %w[info init complete progress close release ur update-roadmap cleanup clean].include? command
58
+ options[:command] = command
59
+ else
60
+ puts "unknown command #{command}".red
61
+ exit
62
+ end
63
+
64
+ unless File.exists? (options[:roadmap])
65
+ puts "No roadmap file (#{options[:roadmap]}) found, can not continue.".red
66
+ exit
67
+ end
68
+
69
+ # switch to init mode unless .dev_flow file exists
70
+ unless command == 'init'
71
+ unless File.exists? (options[:local_config])
72
+ puts "Initializing your environment ... "
73
+ DevFlow.invoke!(options, 'init')
74
+ end
75
+ end
76
+
77
+ if command == 'release'
78
+ options[:release] = true
79
+ command = 'close'
80
+ end
81
+
82
+ DevFlow.invoke!(options, command)
data/dev_flow.gemspec ADDED
@@ -0,0 +1,18 @@
1
+ $LOAD_PATH.unshift File.expand_path('../lib', __FILE__)
2
+ require 'dev_flow/version'
3
+
4
+ Gem::Specification.new 'dev_flow', DevFlow::VERSION do |s|
5
+ s.description = "dev_flow is a bundle of tools for ROADMAP/git based development flow control."
6
+ s.summary = "a bundle of tools for ROADMAP/git based development flow control."
7
+ s.authors = ["Huang Wei"]
8
+ s.email = "huangw@pe-po.com"
9
+ s.homepage = "https://github.com/huangw/dev_flow-gem"
10
+ s.files = `git ls-files`.split("\n") - %w[.gitignore]
11
+ s.executables << "dw"
12
+ s.test_files = Dir.glob("{spec,test}/**/*.rb")
13
+ s.rdoc_options = %w[--line-numbers --inline-source --title DevFlow --main README.rdoc --encoding=UTF-8]
14
+
15
+ s.add_dependency 'term-ansicolor' # for colorful command line display
16
+ s.add_development_dependency 'rspec', '~> 2.5'
17
+ end
18
+
data/examples/ROADMAP ADDED
@@ -0,0 +1,75 @@
1
+ ROADMAP for Dulcinea-Syobu Phase
2
+ ====================================
3
+ Created at 2013-02-25
4
+
5
+ % ----
6
+ title: Dulcinea P.R.T 客户端(syobu阶段)
7
+ status: prototyping
8
+ description: "
9
+ PixPlus.Me的移动客户端,基于corona SDK,涵盖iOS/Android的手机和Tablet设备(P.R.T.三种情况)。Syobu Phase以phone为主,实现主要软件功能的内测版本。
10
+ "
11
+ members:
12
+ lizh: [Li Zhonghua, lizh@pe-po.com]
13
+ sunyr: [Sun Yunrui, sunyr@pe-po.com]
14
+ liudx: [Liu Dongxu, liudx@pe-po.com]
15
+ cuibg: [Cui Baoguo, cuibg@pe-po.com]
16
+ wangqh: [Wang Qinghua, wangqh@pe-po.com]
17
+ supervisor: huangw
18
+ leader: xuyc
19
+ moderator: cuibg
20
+ team: [huangw, xuyc, liudx, cuibg, wangqh]
21
+ year: 2013
22
+ % ----
23
+
24
+ [+] scope: 确定开发范围,拆分单元开发模块 02/25-03/15 @huangw;xuyc
25
+ [++] mod_scope: 开发范围和开发框架概述 02/26-03/15 @huangw;xuyc:40
26
+ [++] unit_tree_tool: 单元构件树状图工具 02/26-03/03 @huangw:03/04
27
+ [++] ui_unit: 用树状图描述UI单元结构 03/04-03/06 @xuyc;huangw:03/06
28
+ [++] rewrite_unit_tree: 重构单元构件树状图及制图工具 03/06-03/18 @huangw:10
29
+ [++] unit_spec: 单元开发部件的式样书草图 02/27-03/20 @xuyc;liudx:10
30
+ [++] frame: 单元-测试-结合的开发框架 03/03-03/20 @huangw;xuyc:10
31
+ [+] proto: 制作移动客户端原型 03/07-03/25 @huangw;xuyc;wangqh;cuibg
32
+ [++] research: 调查开发环境的限制 03/07-03/20 @xuyc
33
+
34
+ [+] model: 人、组、pixplus和clip的基础模型 02/26-03/15 @huangw
35
+ [++] open_search: 调查weibo,facebook等开放服务平台的API 02/26-03/10 @lizh;huangw;cuibg;wangqh:02/28
36
+ [+++] s_sina_tencent: 调查新浪weibo和腾讯微博、QQ的用户、分组和post模型 02/26-03/01 @cuibg:02/28
37
+ [+++] s_renren_douban: 调查人人网,豆瓣网的用户、分组和post模型 02/26-03/01 @wangqh:02/28
38
+ [+++] s_twitter_facebook: 调查Twitter和Facebook的用户、分组和post模型 02/26-03/01 @lizh:02/28
39
+ [+++] s_gplus_pin_tumblr: 调查GooglePlus,Tumblr和Pinterest的用户、分组和post模型 02/26-03/01 @xuyc:02/28
40
+ [++] models_prime: 初步建模 02/28-03/06 @huangw;sunyr;xuyc;cuibg;wangqh;lizh:03/07
41
+ [+++] tables_struct: 生成模型表的基本结构 03/01 @huangw:03/01
42
+ [+++] refine_ts: 详细调整模型表的基本结构 03/02-03/03 @huangw:03/04
43
+ [+++] pic_pix_prime_m: picture和pix模型 02/28-03/06 @sunyr;cuibg:03/04
44
+ [+++] modify_pix_prime_m: 修改picture模型 03/05 @sunyr:03/05
45
+ [+++] user_group_prime_m: 用户和组的模型 02/28-03/06 @lizh;wangqh:03/06
46
+ [+++] fo_clip_prime_m: follower和clip模型 02/28-03/06 @huangw;xuyc:03/07
47
+ [+++] action_prime_m: action和comment相关的模型 03/04-03/06 @huangw:03/07
48
+ [++] milestone_model_0.1: Review Model 0.1 03/06 @huangw;sunyr;xuyc;cuibg;wangqh;lizh:03/14
49
+ [++] models_second: 建模第二步 03/06-03/11 @huangw;sunyr;xuyc;cuibg;wangqh;lizh:03/14
50
+ [+++] pic_pix_second_m: picture和pix模型 03/06-03/11 @sunyr;cuibg:03/12
51
+ [+++] user_group_second_m: 用户和组的模型 03/06-03/11 @lizh;wangqh:03/13
52
+ [+++] fo_clip_second_m: follower和clip模型 03/06-03/11 @huangw;xuyc:03/14
53
+ [+++] action_second_m: action和comment相关的模型 03/06-03/11 @huangw:03/10
54
+ [++] milestone_model_0.2: Review Model 0.2 03/21 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
55
+ [+] app_server: 基于sinatra和rabl的rack服务器架构 03/05-03/25 @huangw:03/10
56
+ [++] rabl: 调查测试rabl(速度、documentation tool) 03/05-03/10 @huangw:03/10
57
+ [++] sinatra: 搭建sinatra基础结构 03/09 @huangw:03/10
58
+ [++] api_test: 使用cucumber或者bunny-carrot(luobo)搭建测试环境 03/09-03/15 @huangw;lizh:03/10
59
+ [+] app_server_revise: 重构新的sinatra rack服务器架构 03/14-03/18 @huangw:03/15
60
+ [+] api_design_prime: 初步设计基本的API结构 03/15-03/30 @xuyc;huangw;sunyr:36
61
+ [+] model_spec: 设计model的测试框架,开始书写spec 03/13-03/30 @huangw;lizh:10
62
+
63
+ [+] release_api_design_0.1: Review API Design 0.1 03/30 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
64
+ [+] api_design_second: 设计基本的API结构第二步 03/30-04/10 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
65
+ [++] api_dsgn_pix_pic_sec: picture和pix的API结构 03/30-04/10 @sunyr;cuibg
66
+ [++] api_dsgn_usr_grp_sec: 用户和组的API结构 03/30-04/10 @lizh;wangqh
67
+ [++] api_dsgn_fo_clip_sec: follower和clip的API结构 03/30-04/10 @huangw;xuyc
68
+ [++] api_dsgn_action_sec: action和comment相关的API结构 03/30-04/10 @huangw
69
+ [+] release_api_design_0.2: Review API Design 0.2 04/10 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
70
+ [+] release_0.1: 搭建完开发环境后发布到测试用服务器 04/10 @sunyr;huangw -> release_api_design_0.1;model_spec
71
+
72
+ [+] implementation: 实现API功能 03/30-04/30 @huangw;sunyr
73
+ [+] test: API功能同步测试 03/30-04/30 @huangw;lizh
74
+ [+] release_0.2: 第一个可以与dulcinea结合的版本 04/30 @sunyr;huangw
75
+
@@ -0,0 +1,75 @@
1
+ ROADMAP for Dulcinea-Syobu Phase
2
+ ====================================
3
+ Created at 2013-02-25
4
+
5
+ % ----
6
+ title: Dulcinea P.R.T 客户端(syobu阶段)
7
+ status: prototyping
8
+ description: "
9
+ PixPlus.Me的移动客户端,基于corona SDK,涵盖iOS/Android的手机和Tablet设备(P.R.T.三种情况)。Syobu Phase以phone为主,实现主要软件功能的内测版本。
10
+ "
11
+ members:
12
+ lizh: [Li Zhonghua, lizh@pe-po.com]
13
+ sunyr: [Sun Yunrui, sunyr@pe-po.com]
14
+ liudx: [Liu Dongxu, liudx@pe-po.com]
15
+ cuibg: [Cui Baoguo, cuibg@pe-po.com]
16
+ wangqh: [Wang Qinghua, wangqh@pe-po.com]
17
+ supervisor: huangw
18
+ leader: xuyc
19
+ moderator: cuibg
20
+ team: [huangw, xuyc, liudx, cuibg, wangqh]
21
+ year: 2013
22
+ % ----
23
+
24
+ [+] scope: 确定开发范围,拆分单元开发模块 02/25-03/15 @huangw;xuyc
25
+ [++] mod_scope: 开发范围和开发框架概述 02/26-03/15 @huangw;xuyc:40
26
+ [++] unit_tree_tool: 单元构件树状图工具 02/26-03/03 @huangw:03/04
27
+ [++] ui_unit: 用树状图描述UI单元结构 03/04-03/06 @xuyc;huangw:03/06
28
+ [++] rewrite_unit_tree: 重构单元构件树状图及制图工具 03/06-03/18 @huangw:10
29
+ [++] unit_spec: 单元开发部件的式样书草图 02/27-03/20 @xuyc;liudx:10
30
+ [++] frame: 单元-测试-结合的开发框架 03/03-03/20 @huangw;xuyc:10
31
+ [+] proto: 制作移动客户端原型 03/07-03/25 @huangw;xuyc;wangqh;cuibg
32
+ [++] research: 调查开发环境的限制 03/07-03/20 @xuyc
33
+
34
+ [+] model: 人、组、pixplus和clip的基础模型 02/26-03/15 @huangw
35
+ [++] open_search: 调查weibo,facebook等开放服务平台的API 02/26-03/10 @lizh;huangw;cuibg;wangqh:02/28
36
+ [+++] s_sina_tencent: 调查新浪weibo和腾讯微博、QQ的用户、分组和post模型 02/26-03/01 @cuibg:02/28
37
+ [+++] s_renren_douban: 调查人人网,豆瓣网的用户、分组和post模型 02/26-03/01 @wangqh:02/28
38
+ [+++] s_twitter_facebook: 调查Twitter和Facebook的用户、分组和post模型 02/26-03/01 @lizh:02/28
39
+ [+++] s_gplus_pin_tumblr: 调查GooglePlus,Tumblr和Pinterest的用户、分组和post模型 02/26-03/01 @xuyc:02/28
40
+ [++] models_prime: 初步建模 02/28-03/06 @huangw;sunyr;xuyc;cuibg;wangqh;lizh:03/07
41
+ [+++] tables_struct: 生成模型表的基本结构 03/01 @huangw:03/01
42
+ [+++] refine_ts: 详细调整模型表的基本结构 03/02-03/03 @huangw:03/04
43
+ [+++] pic_pix_prime_m: picture和pix模型 02/28-03/06 @sunyr;cuibg:03/04
44
+ [+++] modify_pix_prime_m: 修改picture模型 03/05 @sunyr:03/05
45
+ [+++] user_group_prime_m: 用户和组的模型 02/28-03/06 @lizh;wangqh:03/06
46
+ [+++] fo_clip_prime_m: follower和clip模型 02/28-03/06 @huangw;xuyc:03/07
47
+ [+++] action_prime_m: action和comment相关的模型 03/04-03/06 @huangw:03/07
48
+ [++] milestone_model_0.1: Review Model 0.1 03/06 @huangw;sunyr;xuyc;cuibg;wangqh;lizh:03/14
49
+ [++] models_second: 建模第二步 03/06-03/11 @huangw;sunyr;xuyc;cuibg;wangqh;lizh:03/14
50
+ [+++] pic_pix_second_m: picture和pix模型 03/06-03/11 @sunyr;cuibg:03/12
51
+ [+++] user_group_second_m: 用户和组的模型 03/06-03/11 @lizh;wangqh:03/13
52
+ [+++] fo_clip_second_m: follower和clip模型 03/06-03/11 @huangw;xuyc:03/14
53
+ [+++] action_second_m: action和comment相关的模型 03/06-03/11 @huangw:03/10
54
+ [++] milestone_model_0.2: Review Model 0.2 03/21 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
55
+ [+] app_server: 基于sinatra和rabl的rack服务器架构 03/05-03/25 @huangw:03/10
56
+ [++] rabl: 调查测试rabl(速度、documentation tool) 03/05-03/10 @huangw:03/10
57
+ [++] sinatra: 搭建sinatra基础结构 03/09 @huangw:03/10
58
+ [++] api_test: 使用cucumber或者bunny-carrot(luobo)搭建测试环境 03/09-03/15 @huangw;lizh:03/10
59
+ [+] app_server_revise: 重构新的sinatra rack服务器架构 03/14-03/18 @huangw:03/15
60
+ [+] api_design_prime: 初步设计基本的API结构 03/15-03/30 @xuyc;huangw;sunyr:36
61
+ [+] model_spec: 设计model的测试框架,开始书写spec 03/13-03/30 @huangw;lizh:10
62
+
63
+ [+] release_api_design_0.1: Review API Design 0.1 03/30 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
64
+ [+] api_design_second: 设计基本的API结构第二步 03/30-04/10 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
65
+ [++] api_dsgn_pix_pic_sec: picture和pix的API结构 03/30-04/10 @sunyr;cuibg
66
+ [++] api_dsgn_usr_grp_sec: 用户和组的API结构 03/30-04/10 @lizh;wangqh
67
+ [++] api_dsgn_fo_clip_sec: follower和clip的API结构 03/30-04/10 @huangw;xuyc
68
+ [++] api_dsgn_action_sec: action和comment相关的API结构 03/30-04/10 @huangw
69
+ [+] release_api_design_0.2: Review API Design 0.2 04/10 @huangw;sunyr;xuyc;cuibg;wangqh;lizh
70
+ [+] release_0.1: 搭建完开发环境后发布到测试用服务器 04/10 @sunyr;huangw -> release_api_design_0.1;model_spec
71
+
72
+ [+] implementation: 实现API功能 03/30-04/30 @huangw;sunyr
73
+ [+] test: API功能同步测试 03/30-04/30 @huangw;lizh
74
+ [+] release_0.2: 第一个可以与dulcinea结合的版本 04/30 @sunyr;huangw
75
+
@@ -0,0 +1,4 @@
1
+ members:
2
+ huangw: [Huang Wei, huangw@pe-po.com]
3
+ xuyc: [Xu Yichen, xuyc@pe-po.com]
4
+ sunyr: [Sun Yunrui, sunyr@pe-po.com]