Reducing Rakuten Ichiba's development lead time - A Pattern Language-
•Download as PPTX, PDF•
2 likes•1,152 views
I have been trying to reduce the Rakuten Ichiba's development lead time. I want to show our results and future plan. Furthermore I want to show our pattern language for this theme. I am happy if you are interested in some of our patterns and apply it to your own situation and problem. This presentation is English version of the external presentation which was held on 10th Mar. Detail is here https://itmedia.smartseminar.jp/public/seminar/view/687 Keywords are CI, Automation, Deployment pipeline, Continuous system test (CST)
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Reducing Rakuten Ichiba's development lead time - A Pattern Language-
Similar to Reducing Rakuten Ichiba's development lead time - A Pattern Language- (20)
Recently uploaded
Recently uploaded (20)
Reducing Rakuten Ichiba's development lead time - A Pattern Language-
- 1. Reducing Rakuten Ichiba’ s development lead time - A Pattern Language - Mar/10/2015 Takahiro Yamaki Rakuten Ichiba Development Department, Rakuten Inc. http://www.rakuten.co.jp/
- 2. 2 Summary! • Motivation – Faster & Better service delivery • Strategies 1. Automation 2. Quick feedback to coders 1. Build result 2. Static code analysis result 3. Continuous system test (CST) result 4. Security check result Reducing development lead time
- 3. 3 Agenda 1. Introduction 1. My area of responsibility 2. Thoughts to take home 3. Our pattern language 2. Show cases 3. Goal plan 4. Summary
- 4. 4 My area of responsibility in B2B2C Rakuten Ichiba Warehouse (RMS) ShoppersMerchants Selling area (MALL) (1) Reduce development lead time (2) Reduce operational cost
- 5. 5 Thoughts to take home • I’d like to introduce our results and future plan. Furthermore I want to show our pattern language for this theme. • I am happy if you are interested in some of our patterns and apply it to your own situation and problem. おみやげ
- 6. 6 Pattern language for staffs Involve Everyone Evangelist 『Fearless Change: Patterns for Introducing New Ideas』 Mary Lynn Manns, Linda Rising (2014) Dedicated Champion Innovator Early Adopter Study Group Just Do It Plant the Seeds Personal Touch Hometown Story
- 7. 7 Pattern language for development process Git-nization Step by Step Small Successes Automation Repository connection Abolish Excel External Validation Just Enough
- 8. 8 Git-nization Step by Step Small Successes Automation Repository connection Abolish Excel External Validation Just Enough Patterns & Keywords pull-request CI Test case management Branch management git-flow Ticket Code Build, Deploy Test
- 9. 9 Git-nization Step by Step Small Successes Automation Repository connection Abolish Excel External Validation Just Enough Today’s show cases CI Ticket Code Build, Deploy Test (2) (1)
- 10. 10 Agenda 1. Introduction 2. Show cases 1. Repository connection 2. Automation 3. Goal plan 4. Summary
- 12. 12 Pattern: Repository connection • Context –Many lists, memos to relate things. • Have the pull-requests of this issue been finished? • Which environment have you deployed for this issue? • Problem –Difficult traceability –Non-productive costs
- 13. 13 Pattern: Repository connection • Restrictions –Some development tools are in service. • BTS(ticket management), SCM(source code management), Document management • Solution –Select a development system which is close to them.
- 14. 14 Test case Test results Repository connection result Tickets Codes Artifacts Documents Code Quality RMS Build result Deploy result Security reports Info. Storage Restrictions
- 15. 15 Tips for tickets and commit relations Precondition 1. Using git-flow. Branch name is feature/xxxx 2. Using ticket ID for the feature name cd .git/hooks mv prepare-commit-msg.sample prepare-commit-msg vi prepare-commit-msg #!/bin/sh # mv $1 $1.tmp echo -n "[`git branch | grep "*" | awk '{print $2}' | sed -e "s/feature///g" `] " > $1 cat $1.tmp >> $1 Sample code by T. Sugihara
- 16. 16 View from a build result Deploy results Tickets Codes Change log (who? what?)
- 17. 17 View from a test result Tickets Test failure result New ticket Test results Ticket
- 18. 18 MOVIE Test failure report New ticket
- 20. 20 Pattern: Automation • Context – Too many manual tasks • Problem – Much operational cost. Sometimes mistakes. • Restrictions – Some development tools are in service. • Solutions – Select a CI server which is close to them. – Automation! Automation! Automation!
- 21. 21 Automation reference (1) 『Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation 』 Jez Humble, David Farley
- 22. 22 Automation reference (2) 『 Automation for the people: Deployment-automation patterns』 Paul Duvall http://www.ibm.com/developerworks/java/library/j-ap01139/ – One-click – Externalized Configuration – Headless Execution – Scripted Deployment – Remote Deployment
- 23. 23 Automation infrastructure overview CI System
- 24. 24 Demo scenario Application Management server Clusters #1 #2 #3 #4 Manual test Continuous System test* (3) (2) (4) * Kotaro Ogino and Francois Picalausa “Continuous System Test”. Test Automation. http://kokotatata.hatenablog.com/entry/2014/03/14/075842 (1) CI server
- 25. 25 MOVIE Automated build & deploy
- 26. 26 Continuous system test overview Selenium Hub Test case management tool RMS Selenium Nodes Script results manage Manual test results CI server Test data
- 27. 27 Agenda 1. Introduction 2. Show cases 3. Goal plan 4. Conclusion
- 28. 28 STG QA DEVBuild Goal plan ･･･ “Deployment pipeline” IT Release Judge Acceptance Test PROD Blue- Green Deploy Clone Build UT Code Analysis Deploy Conf Test Conf Test Deploy ST Conf Test Code Review Metrics Release Judge Security Test ST Security Test
- 29. 29 Summary! • Motivation – Faster & Better service delivery • Strategies 1. Automation 2. Quick feedback to coders 1. Build result 2. Static code analysis result 3. Continuous system test result 4. Security check result Reducing development lead time
- 30. 30 QA
Editor's Notes
- Good evening everyone, I’m Takahiro Yamaki from Rakuten Ichiba development department. Today I’d like to introduce our challenge to reduce our development lead time. I show not only facts, but also a pattern language to explain what we did.
- First of all, I explain about today’s summary. My motivation for reducing development lead time is to achieve the Faster & Better service delivery. In order to achieve it, we have 2 main strategies. 1st is Automation. 2nd is quick feedback to coders. I think that these are useful feedback to coders. For example, Build result, static code analysis result, continuous system test result, security check result, and so on.
- Now let’s move on to today’s agenda. There are 4 main parts. As for introduction, I explain about My area of responsibility Thoughts which you may take home Our pattern language
- Let me introduce about my area of responsibility in the Rakuten Ichiba B2B2C business model. The center of B2B2C model is mainly separated into 2 big systems. Mall system is like selling area for shoppers (shopping users). On the other hand RMS system is like warehouse for merchants (shop owners and staffs). RMS system consists of shop configurations, item management, payment management, delivery management and so on. I and my team activity target is mainly for RMS. My team has 2 main missions. 1st mission is to reduce development lead time and the other mission is to reduce the operational cost. Today’s topic is about our 1st mission.
- Now here is thoughts to take home. Usually I call it ‘おみやげ’ in Japanese. Today I’d like to introduce our results and future plan to reduce our development lead time. Furthermore I show a pattern language to explain what we did. I am happy if you are interested in some of our patterns and apply it to your own situation and problem.
- I make 2 slides in order to introduce our pattern language. This slide is for staffs and the next slide is for development process. These patterns and pattern relations (it is called pattern language) are overview of what I’ve done for 2 years, step by step. These pattern names come from the “Fearless change”. Japanese version title is ‘Fearless Change アジャイルに効く アイデアを組織に広めるための48のパターン’ First of all, when I joined Rakuten, there were too many manual operations. I felt tired of those operations. So I was strongly interested in any automation to reduce my manual operation cost. Then I tried to implement a build automation sample using our team software. Then I did study group to share my success. When I look back to these activities, I think ‘Evangelist’ pattern, ‘Just Do it’ pattern, ‘Study Group’ pattern, are good description. If I find someone who interested in my story, I went next to him/her, I made hands-on-training, made automation plan using his/her application. After that they became innovators in our group, then they YOKOTENed their success to their colleagues. Then their colleagues are becoming the early adopters in our group. Currently we are in this stage. I think we need to involve everyone in order o achieve our goal. エバンジェリスト Evangelist, やってみる Just Do It 勉強会 Study Group, 体験談の共有 Hometown Story, 種をまく Plant the Seeds 正式な推進担当者 Dedicated Champion 個人的な接触 Personal Touch イノベーター Innovator, アーリーアダプター Early Adopter, みんなを巻き込む Involve Everyone
- This slide is for development process. Bold frame shapes are not in the “Fearless change”. I thought extra 4 patterns which described what I did in order to improve our development process. These are ‘Git-nization’, ‘Automation’, ‘Abolish Excel’ and ‘Repository connection’.
- Now I put some keywords with these patterns. For example we changed the branch management, review management as part of Git-nization. We selected ‘git-flow’ as branch management model. I think ‘External validation’ pattern is good description for this activity. As for ‘Abolish Excel’ pattern, our test case management is shifting from Excel files to a suitable management tool. As for ‘Repository connection’ pattern, I am trying to connect some repositories which are for tickets, codes, build results, deploy results, and test cases.
- Today I introduce these 2 patterns in detail.
- Let’s move on to the show cases part.
- I explain our ‘Repository connection’ pattern. The context of this pattern is like this. There are many lists and memos to relate things. (Things are issues, codes, build results, deploy results, and so on) For example, ‘Have the pull-requests of this issue been completed?’ ‘Which environment have you deployed for this issue?’ The problem of this pattern is the ‘difficult traceability’. Even if it is not difficult for you to manage them, I think you pay some cost which is not productive.
- You may think or know some solutions for these kind of problems. There was a restriction for me to select one solution among them. That is to say, some developments tools had been already in service. They are BTS (bug tracking system, Jira), SCM (source code management, Stash) and Document management (Confluence). So the solution was to select a development system which was close to them.
- This diagram is about our repository connection result. This left-upper area is the restrictions. These development tools have already been in service. So I selected development tools which were close to these restrictions.
- This slide is just only a tips to related tickets and commits.
- This capture is a view from a build result. From this page you can trace which environments this build artifacts are deployed to. Furthermore you can see what kind of modifications or tickets are adopted between previous build and this build. So when a build fail, you may find who is the crasher.
- This capture is a view from a test result. When you input test failure comment in the test case management tool, you can create a issue by just only a few clicks. After that you can trace the issue from the test case failure result. And you can trace the test result from the issue, too.
- Now I show you the Movie about this process.
- Now let’s move on to the next show case. 2nd show case is about automation.
- I explain this automation pattern a little bit. The context of this pattern is that there are too many manual tasks. The problem is that they takes much cost and they sometimes lead to mistakes. The restriction is as same as ‘repository connection’ pattern. So the solution is as same as repository connection’ pattern. I selected a CI server which is close to the existing development tools.
- Here is a reference book for my automation activity.
- Or you may see the overview about what kind of automation patterns are useful for you.
- Now this is our automation infrastructure overview. The left area is for our CI system. This covers not only PROD environment but also DEV, STG environment.
- Before I show a movie about a build and deploy automation, I explain the scenario a little bit. Today’s demonstration movie is a internal tool. It is running on the GlassFish application server. Today’s demonstration steps are (1) I make a new branch and push it (2) CI tool detects the new branch and it copied the build process automatically. Then I start a build, (3) a war file is transferred to the GlassFish management server. (4) Bamboo kicks the deploy command to one of clusters. Usually we start to do manual tests or automated UI regression test to the new version. We call it “continuous system test”. Please refer this content which is written by Ogino-san about the concept, background and solution for the continuous system test.
- Now I show you the Movie about our build and deploy automation.
- So let’s move on to the last automation topic. Last automation topic is about continuous system test. The main technology is Selenium Hub & Nodes (The nickname is selenium2. Previously it was called Selenium Grid or selenium web driver) We prepares test scripts which consists of input data properties, test steps and expected result. Bamboo request the UI regression test to the selenium Hub, and then UI tests are executed in each Selenium Node. After the UI regression test finish, Bamboo puts the test result in our Test case and result management tool. So project leaders can see the test results using 1 tool.
- Let’s move on to the last topics.
- This is our goal plan. Usually it is called “deployment pipeline”. Red icons stand for automated tasks. On the other hand blue icons stand for manual tasks. The left cube is for building stage. It consists of build, UT and static code analysis. Then a coder get these feedback from our development pipeline. When the 1st build stage is success, the next DEV stage starts. The artifacts are deployed to the servers, configuration tests, continuous system tests and security tests are executed step by step. After these automated tasks finished successfully, a tester starts to do an integration test. The metrics which is from static code analysis, code review and IT results are inputs for development leaders who decide whether the artifacts have enough quality to deploy to STG environment.
- I repeat today’s summary. My motivation for reducing development lead time is to achieve the Faster & Better service delivery. In order to achieve it, we have 2 main strategies. 1st is Automation. 2nd is to return quick feedback to coders. I think that these are useful feedback to coders. For example, Build result, static code analysis result, continuous system test result, security check result, and so on.
- These are about our challenge and a pattern language. It is under construction. Do you have any questions or comments?