best practice讨论/交流

gzrain

其实有这个想法很久了，做IT的，局限与自己的公司/projects，很多时候都是在做相近的东西， 和外界industry流行趋势接触比较少。希望接这个机会交流一下， best practice，或者tips and tricks。我相信每个人的经验和做法都有值得学习的地方。

简单介绍下自己，半路转行的dev，现在在做RubyOnRails， Sydney

1. Development Cycle

直到我现在工作的公司，之前的公司，可以说完全没有release cycle， 想到那做到那，做到那deploy到那。印象最深的一间公司，号称 ”Customer Oriented“  ， 客户一个电话过来，我们这边就要drop everything and fix it (and deploy) right away. 最大的问题是project没有write test code。那时候我到公司不久，还在熟悉中，跟经理说了无数遍 I can make this fix now but I have no idea whether it will break other places in the system.  经理： customer are shouting at me in the telephone, just do it!

结果真是nightmare， we keep introducing more bugs while trying to fix them, without test code. 这个project可想而知， 很长一段时间都在痛苦挣扎中。

后来到了现在的公司，有了相对正规的开发流程，感觉流程对开发质量的确有很大帮助，at some point you have to say NO to customer, 你有新需求，你发现了bug，可以，我们会记录下来，会根据priority在下个release添加。下面简单介绍我们公司的release cycle。 先声明，这只是一家的做法，希望抛砖引玉，也希望听听其他公司是怎么操作的。

release cycle : every 3 weeks (15 working days)
pre-release cycle:  BA and Support team gather issue and bug reports and writing tickets

Day 1: Team Lead and business Team has planning meeting. discuss tickets details
Day 2 - 13: Devs take over, develop tickets base on the priority, for those tickets finished, marked as 'ready' and deploy to staging server so that business team and customer can test them.
Day 14 - 15 EVERYONE in the company do the finial testing and deploy.

So far the company has been using this cycle for over 3 years and it works.

我也很想听听别的公司都是怎么做的呢？

虞宅与美丽

支持楼主。高个亮让更多人看到参与。

joerkky

每个公司的资源，所在的环境，项目的特性，大家对开发认识的差异，都会导致practice的不同，没有silver bullet这么一说

比如说，web based startup可以做MVP（minimal viable product），政府项目就很难，所以practice可以有很多，是不是best就具体情况具体分析了

我先抛砖引玉，把我们的practice列一下

Release cycle: 没有release cycle, continuous delivery，每个check in都会自动trigger automation, 测试通过之后就可以merge到master，然后release。未完成的feature在production用feature toggle关闭。

Inception: stakeholder, PM, BA, Architect, Dev, QA开会（会程一天到一周），同意所要做的内容，写user story, 如果需要steering，会邀请steering committee参加

SDLC:
BDD style，每个user story开始的时候，BA，Dev，QA，product owner会碰头，一起写feature file, 然后Dev写代码，QA写automation，完成(code review, stakeholder review)之后大家再碰头确认feature complete

Product指导思想：MVP
Agile methodology: Kanban +Lean

gzrain

joerkky 发表于 2014-5-23 08:52
每个公司的资源，所在的环境，项目的特性，大家对开发认识的差异，都会导致practice的不同，没有silver bul ...

感谢joerkky的分享，写得比我详细多了。

感觉你的流程很正规啊， 各种role的责任都很分工明确； 我在一间小公司，没有那么多资源，很多时候责任流程比较模糊，不过在过去1年Team lead花了很大的功夫慢慢完善流程和各种工具的运用。另外小公司有个特点，说得好听就是灵活，不好听就是容易受影响，客户和政策的变化可以直接影响开发priority，不过好处也是反应快，希望大家继续分享。

gzrain

2. repository control

这个相对简单点，估计现在很多开发公司都在用了，基本就是GIT/Pull Request的模式， 流程：
1. developer create and work under correspondent working GIT branch of each ticket
2. developer commit changes and create Pull Request
3. team member review Pull Request,  give feedback or accept the request.
4. changes merged into master branch and remote working branch is deleted

公司因为政策的原因，不能使用github，而是使用自己server hosting的Gitlab，功能大同小异。
我听说有些consultant公司对commit message格式也有严格要求，Pull Request必须有2个以上team member review后才能accept。

在这套流程普及以前，有个叫git flow的git plugin，本质上和这个流程也是一样的.

这套流程我觉得最有用的就是引入了code review，group the commit by working branch bases. 另外我现在通常的习惯是在Pull Request前rebase一下最新的master，这样conflict会比较容易处理些， github/gitlab也能直接accept request。

mengqing

LZ现在在哪家公司做rails?

我在公司的流程是

因为是one man team，所以直接master branch，除非做feature

要写testing老板说没空 然后直接deploy

rogerkong

没在澳洲大公司做过，感觉这里的流程比较乱，职责界定模糊不清，不过可能只是我在的这家公司

无翅之徒

要取决于项目的大小和性质 不是所有的项目都是适合AGILE的。
AGILE 很重要的一点是你要有 DEDICATED CUSTOMERS, 但是 REALITY是CUSTOMER 不给你添乱就不错了

无翅之徒

rogerkong 发表于 2014-5-28 10:16
没在澳洲大公司做过，感觉这里的流程比较乱，职责界定模糊不清，不过可能只是我在的这家公司 ...

大公司有更多的 POLITICAL GAMES 影响流程 影响进度 基本上影响EVERYTHING 但是你永远也摆脱不了

muyir

基本上去学习一下agile怎么做，或多或少的的把其中的一些practice用到自己项目中，就可以事半功倍
比如：
planning meeting
retrospective meeting
daily scrum
continue integration
...

gzrain

mengqing 发表于 2014-5-28 00:54
LZ现在在哪家公司做rails?

我在公司的流程是

I work in a small company with a team of 6-7 devs. I think it's pretty important that a senior dev to guide you, even you can learn a lot in the discussion between team members. I know sometimes it could be frustrated for a one-man team, where you got no one to talk to.

I suggest you can have a look on git-flow, it 's quite useful even for one-man team as you can separate feature/hotfix branches.

mengqing

gzrain 发表于 2014-5-29 20:19
I work in a small company with a team of 6-7 devs. I think it's pretty important that a senior dev ...

I do use git-flow at the moment, just a bit tedious to manage and sort of useless when you're the one doing it all..

ttma1046

楼主亲!

工具方面无需多讲
版本控制大同小异, git, tfs, mercurial 和 tfs的board 或者各种Atlassian的 产品，stash，bitbucket,gitlab,github连在一起。Bamboo或者teamcity作CI。Deploy现在有个东东叫octopusdeploy。

mengqing

最近一直在研究microservices，不知道有人对这方面有经验的。想在以后的greenfield projects用上
现在看下来microservices有些缺点，too chatty, transactional rollback, resources, deployment

有人现在在用microservices吗

浮云马

mengqing 发表于 2015-2-24 16:16
最近一直在研究microservices，不知道有人对这方面有经验的。想在以后的greenfield projects用上
现在看下 ...

你说得很对，Microservices不是silver bullet，能不能有用还是得看你具体的问题。

就拿transaction来说吧，数据量不大，业务逻辑不是很复杂的情况下，transaction很方便，但是当你的数据量级达到像亚马逊的程度，实现transaction的代价就太大了-CAP theorem，consistency,availability, partition中间你只能选两个，所以很多时候牺牲的就是consistency，只要eventually consistent就已经够好了。

同样的，部署和维护，如果公司以前都是monolithic程序的，一下子转向micro services，会有很多部署和维护上的麻烦，这些都是micro services的代价。

还有就是micro services意味着每个team都是自主的，对外部资源的dependency很少。如果你们公司的organization structure不支持这样的team，也很难搞得起来。

当然好处也很多，scalability，autonomy，loose coupling，continuous integration & deployment，等等

光脚族，觉得有用就加加分呗

mengqing

浮云马 发表于 2015-2-24 18:07
你说得很对，Microservices不是silver bullet，能不能有用还是得看你具体的问题。

就拿transaction来说 ...

能到亚马逊级别的流量的时候 也不缺钱来请牛人们来解决问题了。。你们现在在用microservices么 就还是拿transaction来说 如果流量还没到亚马逊级别的话用什么办法来解决比较好

研究下来也就两种办法 一个就是你说的eventual consistency, 可以用background job来queue service calls，失败了可以retry. 但是这个办法的前提是retry可以成功 不然就是个无限循环了。

还有个办法就是compensating consistency, 当一个service call失败时 之前的services全部来个delete call. 但如果delete call失败了怎么办。

ggt20

求普及：microservices是什么，和SOA有什么关系，和开发流程有什么关系，具体和Developer有什么关系？

ggt20

另外，2~3个人的小团队，基本上每个人一个单独的项目，CI用处大吗？

ggt20

deployment都是自动的吗？一般多大的项目和团队需要有专门的人搞deployment。现在的小公司，developer恨不得从requirement doc开始一直弄到产品服务器的部署

gzrain

浮云马 发表于 2015-2-24 17:07
你说得很对，Microservices不是silver bullet，能不能有用还是得看你具体的问题。

就拿transaction来说 ...

感谢分享


月初去了mel一个conference， 好几个talk都跟SOA粘点边，看来是最近的一个趋势了。但是我对SOA也就停留在概念上，具体完全架构采用SOA的我还没有机会接触过。公司的project现在慢慢把小模块抽离出主app， 使用一些小service，api， queue job，我觉得也勉强有点SOA的影子吧。像是你们说的，具体到impletmentation， 会有很多具体问题，但是如果没有一个real project，很难自己去想像会实际遇到什么问题。 这边small，medium size的project似乎SOA有点牛刀杀鸡，大公司敢用这种新技术的要很久，比较难有直观概念， 最好有实际经验的同学介绍详细点就好了

gzrain

ggt20 发表于 2015-2-24 21:27
求普及：microservices是什么，和SOA有什么关系，和开发流程有什么关系，具体和Developer有什么关系？ ...

1. 具体概念，建议去看wiki， 有详细概念，别人回贴三言两语很难完全解释清楚

2. 我觉得ci就是你development cycle的一个工具而已， 你在ci上run完test才deploy，那也要你先写了test才行； 有了test，是在dev环境run还是在ci上run，没本质区别

3 deployment如果已经setup好环境的话，也就run个script或者按个button而已

ggt20

gzrain 发表于 2015-2-24 22:54
1. 具体概念，建议去看wiki， 有详细概念，别人回贴三言两语很难完全解释清楚

2. 我觉得ci就是你develop ...

多谢讲解，学习中...这IT新概念也太多了，从学到能用上不轻松啊

shalwei