O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a navegar o site, você aceita o uso de cookies. Leia nosso Contrato do Usuário e nossa Política de Privacidade.
O SlideShare utiliza cookies para otimizar a funcionalidade e o desempenho do site, assim como para apresentar publicidade mais relevante aos nossos usuários. Se você continuar a utilizar o site, você aceita o uso de cookies. Leia nossa Política de Privacidade e nosso Contrato do Usuário para obter mais detalhes.
Good evening everyone, I’m Takahiro Yamaki from Japan RMS Group, Japan Ichiba Section. Today I’d like to introduce our daily work to you from the view point of our daily development tools & processes. ---- みなさんこんにちは 日本市場課 日本RMSグループの山木隆寛です。 今日は日本市場の日々の仕事の様子を、ツールやプロセスといった観点からお話したいと思います。
Before we begin, let me introduce myself. I started my career at an information technology service company and I worked in front line teams or support teams. The ratio was 50-50. In this period I used some development tools like Trac, Redmine, TestLink, Microsoft Team Foundation Server, and so on and became a tool lover. (強調 しり上がり)
--- 私の自己紹介をさせていただきますと、情報技術サービス会社のエンジニアとして2004年からキャリアをスタートしました。 前線(front line) と サポートチームでの仕事が半々でした。 この期間に、TracやRedmine、TestLink、MS Team Foundationといったツールを使っていくうちに、段々と開発ツール愛好家になっていきました。
I joined Rakuten in 2012 and I got assigned to Japan Ichiba section, Japan RMS Group. As an application engineer, I developed the purchase history and the shopping counter for Super Sale or monthly sale event.
Kaizen team was established in Japan RMS group this year. This team has 3 missions. Development improvement, operation improvement and new comer training for Japan RMS group. As a productivity engineer I am leading the CI-nization for Japan RMS Group.
And let me also introduce about RMS group in the Rakuten B2B2C business model. The center of B2B2C model is mainly separated into 2 big systems. Mall system is like shopping floor for shopping users. On the other hand RMS system is like backyard for shop owners and staffs. RMS system consists of shop configurations, item management, payment management, delivery management and so on.
Now here is my goal of today’s presentation. It is to change your impression of Japan ICHIBA DevOps!
I’d like to explain what I mean. ---- 私の今日の目標は、日本市場の開発・運用に対するみなさんが持っているイメージを変えることです。
Japan Ichiba system is the oldest system which was created from the beginning of Rakuten. So you may have the impression that Japan ICHIBA daily work is old-fashioned or legacy or something like that! For example, when we go to the orientation for our company’s new grads in spring or autumn, they don’t seem to have positive images for the Japan Ichiba.
My goal of today’s presentation is to change your impression to … And I hope you’ll be more interested in working in Japan ICHIBA by the end of this speech.
Now let’s move on to today’s agenda. Today I want to introduce our daily work from 3 view points. 1st view point is Ticket Driven Development & Operations. 2nd is the automation. 3rd is tools connectivity.
1st topic is about Ticket Driven development & operations.
This diagram is the summary for our development ticket workflow. These database icons stand for jira projects. A jira project is a collection of tickets. Merchants’ requests for new features or improvements are directly or indirectly added in the ‘Backlog’ project. We add these kind of tickets by ourselves.
These backlog tickets are rearranged at fixed intervals. When a ticket get an approval to be implemented, this ticket is moved to the ‘Execution’ project. In this ‘Execution’ project there are tickets which is assigned to someone. Each team leaders report these ticket progress to managers. On the other hand for the front line members we usually use each service jira project. The reason is that it is easy to divide the tickets for development members. When we need to collaborate with infra structure team, we link our tickets to the request tickets for infra teams. As a result the history of each system is stored in these service jira projects.
Furthermore there are some tickets which are directly added in the ‘Execution’ project. For example, security service team sometimes give us alerts for vulnerabilities. ----
Let’s move on to the operation part. This diagram is the summary for our operation ticket workflow. When merchants have something to tell, they contact with Call Center Group or their EC consultants who are the 1st contacts for merchants. When shopping users have something to tell, they contact with Member Service Group who are the 1st contacts for shopping users. If 1st contacts are not able to resolve something, they escalate them to the support Group (we usually call them Helpdesk). They communicate using tickets.
If helpdesk are not able to resolve something, they escalate them to us. When we are not able to fix them soon, we add them as backlog ticket or execution ticket.
On the other hand business unit members have sometimes inquires for us. We made a jira project as the contact point to handle these kind of tickets.
Do you have any questions or comments about this part?
Let’s move on to the next topic. 2nd topic is about automaton.
Ichiba began to use Atlassian tools.
What I did to drive our development automation? I looked backward to make this presentation.
What I experienced may be helpful to you or somebody in the world.
I think a marketing framework and the number of stakeholders are helpful to understand what is going on in the RMS group. AMTUL is the marketing frame work. It stands for Aware, Memory, Trial, Usage and Loyalty.
After I experienced application development for 1 year, I realized that Build Automation is the most effective point in order to drive development automation. So I emphasized Build automation to our group members.
These phases are Aware & Memory phases.
Furthermore I think that the followers are important in order to make a movement. So I did training for someone who are interested in CI. Currently I coordinate these build automation or test automation training as one of the RMS new comer boot camp menus. That’s how we’ve been able to increase automation lovers gradually.
Currently I am working on explaining our organization’s blueprint about development automation. This kind of blueprint prevents your stakeholders from misunderstanding where we go. Using this blueprint you may find what is the most effective point to drive your automation.
This graph shows the number of build automation java projects. 1st 6th months were investigation and demonstration period for us. Next 6 months are rollout phase for other java applications. Next 3 months are expansion. The reason is that 1 giant ant project was divided into 64 maven projects. So about 90 java projects are managed by our CI tool.
We use Atlassian Bamboo as CI tool. It is almost as same as Jenkins. This diagram shows the basic design for our java projects. There are separated stages for each environments. For examples development, staging and production environment. Each stage has some tasks, for example code clone, build and deploy it to each environment. After DEV stage finishes, next STG stage starts. There is a check point between STG and Production stages. After we push a button, the final stage starts. We don’t use deploy command for production environment. When our system come to near the blue print, automated release may be implemented.
Today’s demonstration 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) @Bamboo 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.
So let’s move on to the last automation topic. Last automation topic is about continuous system test. We have started to try it from this autumn. So this diagram is not the final version. 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 and test data which consists of input data and expected result. This test data format is json. 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. We use TestRail as our test case and result management tool. So project leaders can see the test results using 1 tool.
This is our blueprint for our development automation. The most different point from current one is that there is only 1 build stage. It mean that 1 binary artifact is tested in several stages. 2nd different point is that automated tasks and human judgment are integrated as 1 build pipe line.
These are about our development automation. It is under construction. So when I have a chance to talk about our automation season 2, I may talk about more automated tools and processes. And I hope so.
Anyway do you have any questions or comments?
Let’s move on to the last topic. 3rd topic is about tools connectivity.
This diagram describes our development data allocation. They are tickets, documents, codes, test cases, test results, artifact, builds results and code quality metrics data. These ‘Like’ icons are the points which I introduce you today. 1st is the connectivity between tickets and codes. 2nd is the connectivity between build results and tickets, codes. 3rd is the connectivity between Test Results and tickets.
This screen shot shows that Stash pull request and jira tickets are connected each other. So someone can trace why these codes are modified Or someone can trace what kind of codes are effected by this ticket.
This screen shot shows that when a tester inputs some comments as the test fail report, the comment and test preconditions, test steps and expected results are copied to a jira ticket. After that test result report and a jira ticket are connected each other. A coder get a bug report, the ticket has enough information to debug the problem. I like this feature!
[Rakuten TechConf2014] [C-6] Japan ICHIBA Daily Work - Tools & Processes
Japan ICHIBA Daily Work
- Tools & Processes -
Japan RMS Group, Japan Ichiba Section, Rakuten Inc.
About Me and Development Tools
• Name: Takahiro Yamaki
• 2004 ~ 2012
– An information technology services company
– Front Line Team, Support Team
– Development Tool Lover
• Trac, Redmine, SVN, TestLink, MS TFS,
About Me and RMS Group
– Rakuten Ichiba Development Department
• -> Japan Ichiba Section
• -->> Japan RMS Group
– Application Engineer
• Purchase History
• Shopping counter for the Super Sale, sale
• … etc.
About Me and Kaizen Team
– Kaizen Team in Japan RMS Group
• For Japan RMS Group
– Productivity Engineer
About RMS Group in the B2B2C model
My Today's Goal
your impression of
Japan ICHIBA DevOps.
My Today's Goal
Not so Bad
I like to work in Japan Ichiba!
Japan ICHIBA DevOps Daily Work
Table of contents
1. Ticket Driven DevOps
3. Tools Connectivity
Japan ICHIBA DevOps Daily Work
Table of contents
1. Ticket Driven DevOps
3. Tools Connectivity
Development Ticket Flow
Ops Ticket Flow
Demo : Auto Deploy
System Test *
* Kotaro Ogino and Francois Picalausa
“Continuous System Test”. Test Automation.
Continuous System Test (Current)
(Test Case & Results Management)
<Future> Develop & Release Flow