320 строки
19 KiB
Markdown
320 строки
19 KiB
Markdown
---
|
||
layout: post
|
||
title: "Modernizing customer support through augmented/virtual reality and DevOps"
|
||
author: "Manuela Rink"
|
||
author-link: "#"
|
||
#author-image: "{{ site.baseurl }}/images/authors/photo.jpg"
|
||
date: 2017-01-09
|
||
categories: [DevOps]
|
||
color: "blue"
|
||
image: "images/reflekt/feat_0_current_public.jpg"
|
||
excerpt: Developing cross-platform AR apps is much more effective with a valid DevOps chain in place. That's why RE'FLEKT and Microsoft teamed up to implement an end-to-end solution.
|
||
verticals: [Professional Services]
|
||
language: [English]
|
||
geolocation: [Europe]
|
||
#permalink: /<page-title>.html
|
||
---
|
||
|
||
RE’FLEKT is currently on its way to implementing DevOps companywide. With its upcoming product—the Tele-Service platform—which is currently in development, RE’FLEKT will lay the foundation for a globally scalable best practice in DevOps.
|
||
|
||
In this hackfest we focused on the pain points of the currently used build automation and how the future build chain can support front-end as well as back-end development needs in an optimal way.
|
||
|
||
## Customer profile
|
||
|
||
The augmented and virtual reality experts at RE'FLEKT are changing the way we use technology. Founded in 2012, RE’FLEKT has evolved into Europe’s leading expert for business solutions including augmented and virtual reality. At its Munich, Düsseldorf, and Los Angeles offices, more than 50 employees from across the globe create interactive applications for industry, media, and marketing. RE’FLEKT focuses on the development of user-oriented content platforms for augmented and virtual reality. Its customers include Alstom, Audi, BMW, Bosch, Hyperloop, Porsche, ProSiebenSat.1 Media, and ThyssenKrupp, among others. RE’FLEKT conducts its own research in cooperation with the University of Michigan-Dearborn and the Technische Universität München.
|
||
|
||
[https://www.re-flekt.com/](https://www.re-flekt.com/)
|
||
|
||
### The focus product—the Tele-Service platform
|
||
|
||
The Tele-Service platform allows companies to provide a smart visual service to their customers. The application enables users to get easily connected with the right experts to solve issues and answer questions remotely by sending support requests or dialing in directly from a smartphone, tablet, or AR glasses. The expert is able to access the shared camera video stream of the requester and can give advice on the requester's mobile device enriched with augmented reality features.
|
||
|
||
Customers are getting a smart connected visual service that helps companies reduce machine downtimes and travel time even in areas with low network connectivity.
|
||
|
||
### The team
|
||
|
||
The following people were part of the hack team:
|
||
|
||
- Reginald Rink – Product Manager, RE’FLEKT
|
||
- Johannes Ebner – Backend Developer, RE’FLEKT
|
||
- Adam Russell – Test Engineer, RE’FLEKT
|
||
- Sviatoslav Kovtunenko – Backend Developer, RE’FLEKT
|
||
- Manuela Rink – Technical Evangelist for Mobile Platforms, DevOps and Azure, Microsoft
|
||
- Daniel Meixner – Technical Evangelist for DevOps, Visual Studio and Azure, Microsoft
|
||
- Peter Kirchner – Technical Evangelist for DevOps, Azure and Service Fabric, Microsoft
|
||
|
||
### The setup
|
||
|
||
We divided the hackfest into two parts:
|
||
|
||
- A theoretical and analytical part (5 hours)
|
||
- A hands-on and technical deep dive (2 days)
|
||
|
||
During the analytical part, we focused on understanding the current situation, finding the pain points, and thinking of ways to solve them. The most important part was to always keep the big picture in mind, because we wanted to create a solution that should basically work as a blueprint for the company’s DevOps needs. To achieve our goal we used Value Stream Mapping to get the ideas down on paper and to ensure that we have a common understanding of the current situation and the future solution.
|
||
|
||
For the hands-on and technical deep dive, we gave ourselves two full days of hacking. To get all things done—which we summed up during the analytical part—we defined a detailed agenda and were strict on time keeping. This worked out well because everyone on the team was focused on tasks in their own areas of expertise.
|
||
|
||
We intentionally left a whole day’s time between the two parts of the hackfest to be able to digest the analytical outcome and do some preparations for the practical part.
|
||
|
||
## Identifying the problems
|
||
|
||
To get a grip of the current build and deployment automation at RE’FLEKT, we took a deep and detailed look into the build chain of another product, the REFLEKT 360 platform. This takes 360° video content to the next level by adding interaction to it. REFLEKT 360 can be used to showcase new products, see new buildings before they are built, or tell a story in a new and innovative way.
|
||
|
||
<img src="{{ site.baseurl }}/images/reflekt/0_current_public.jpg">
|
||
|
||
|
||
### Find and identify problems in the front end
|
||
|
||
Most of the applications at RE’FLEKT are realized with Unity because of the focus of AR/VR components. The decision to use Unity Cloud Build was an easy one—basically a ready-to-use cloud DevOps service. It pulls the code from the repository, builds the project, and packages and deploys the installable artifacts into its own web-hosted storage.
|
||
|
||
To be able to have full control of the process and have access to the build server’s hardware—e.g., to attach physical test devices—RE’FLEKT wants to use its own build chain, which is maintained in-house.
|
||
|
||
The quality is ensured only by manual testing at this time, but there is no infrastructure yet to run automated UI tests, for example. Setting up this process would increase the efficiency of the QA to get it fully integrated into the development and deployment workflow.
|
||
Additionally, a Jenkins with an attached SonarQube instance is in place and runs in parallel to the Unity Cloud Build process. The reports and findings of this step are currently not used in the process.
|
||
|
||
On the basis of this architecture, we identified the pain points as illustrated in the following image.
|
||
|
||
<img src="{{ site.baseurl }}/images/reflekt/0_current_pain_public.jpg">
|
||
|
||
|
||
### Solve issues and define goals
|
||
|
||
Because the current product should provide a client solution for mobile platforms as well as Windows desktop, Xamarin should be used for cross-platform development.
|
||
|
||
As a substitute for a proper build system, Jenkins should be used as a master build server with proper build workers attached for the target client environments. Because the creation of an iOS executable needs a macOS environment and the UWP one needs Windows, those two operating systems will be used as build workers for Jenkins.
|
||
|
||
To solve the issue of the unsatisfactory integration of the QA in the build and deployment process, we took care of proper automated testing and UI testing in the simulator/emulator as well as on real devices. This automatically sets the need for physical build workers to be able to attach real mobile devices to the machines for UI testing.
|
||
|
||
The technology stack that should be used for the front end is the following:
|
||
|
||
- Jenkins as the dedicated master build server.
|
||
- A Mac and Windows build worker for Jenkins.
|
||
- GIT for source code version control.
|
||
- Appium for automated mobile UI testing.
|
||
- Hipchat as the single point of collaborative communication companywide.
|
||
- With notifications attached from, for example, HockeyApp, Jenkins, and so on.
|
||
- HockeyApp as a sole provider for installable artifacts for all platforms (iOS, Android, UWP).
|
||
- Cake for creating build system-independent build scripts.
|
||
- Visual Studio and Visual Studio Code for front-end development.
|
||
|
||
<img src="{{ site.baseurl }}/images/reflekt/1_frontend_goal_public.jpg">
|
||
|
||
|
||
### Dealing with the back end
|
||
|
||
Regarding the back-end automation story, we had to make up our minds and focus on the specific needs of the Tele-Service platform—for front-end as well as back-end requirements.
|
||
|
||
RE’FLEKT is widely focusing its product development of front-end client-facing solutions. So the need for its own dedicated back-end system for the Tele-Service platform is quite new to the company, which puts even more weight onto the need for build and deployment automation.
|
||
|
||
Learning from the front-end pain points, we integrated the following into the goal architecture:
|
||
|
||
- Hosting a master build server with proper workers to have full control of the build process and times.
|
||
- Taking care of a deep integration of QA in the whole process.
|
||
- Linking all steps nicely together with no stand-alone solution.
|
||
|
||
The technology stack that should be used for the back end is the following:
|
||
|
||
- Azure Service Fabric cluster for the media services.
|
||
- Jenkins as a build server (master).
|
||
- Hosted in an Azure virtual machine.
|
||
- If needed, build workers for Jenkins master.
|
||
- GIT for source code version control.
|
||
- Swagger API for documentation of the client-facing API as well as for live testing.
|
||
- Azure Functions for providing a mock server.
|
||
- Needed until the “real” back end can provide all necessary client-facing APIs.
|
||
- Reuse example JSON data from Swagger as return data for endpoints
|
||
- Hipchat as the single point of collaborative communication companywide.
|
||
- With notifications attached from, for example, Jenkins, Swagger, mock server, and so on.
|
||
- Cake for creating build system-independent build scripts.
|
||
- Visual Studio and Visual Studio Code for C# back-end development.
|
||
|
||
The result is illustrated in the following image.
|
||
|
||
<img src="{{ site.baseurl }}/images/reflekt/2_backend_goal_public.jpg">
|
||
|
||
|
||
## Our goal commitment
|
||
|
||
As we had collected a lot of input on the current situation and tried to learn from it, we challenged ourselves with the following commitment for the hands-on part of the hackfest:
|
||
|
||
- Implement the DevOps chain from end to end for the front-end development story.
|
||
- Get input in deploying a secure Service Fabric Cluster.
|
||
|
||
## Implementing the solution
|
||
|
||
It was important to have a clear understanding of what goal should be reached and how to get there.
|
||
|
||
### Hands-on Day 1
|
||
|
||
Before we got into the hacking part, we validated our goal architecture—the outcome of the Value Stream Mapping—as a group. This was important because, with a few days of distance from the theory day, we wanted to make sure we were still all on the same page and wanted to reach the same goal.
|
||
|
||
This is a crucial step. It gives all attendees the possibility to think about the outcome and defined goal again and have the chance to change bits and pieces if necessary.
|
||
|
||
We started the hacking by structuring our hands-on work on a topic basis for each attendee and clearly formulated our goals:
|
||
|
||
- Drop an installable to HockeyApp via API usage.
|
||
- Drop an installable to a real device.
|
||
|
||
By the end of the day, with a lot of communication and proof-of-concept work done within the team, we reached both of our goals!
|
||
|
||
The following listing gives a good insight into the details:
|
||
|
||
- Jenkins is up and running.
|
||
- Mac/Windows workers up and running and connected to master.
|
||
- Builds of both platforms (iOS and Android) basically running.
|
||
- Basic HockeyApp integration in place.
|
||
- Integrate it to the build chain.
|
||
- Markdown-styled release notes via command line upload.
|
||
- Appium attached to build chain and running on the Jenkins system.
|
||
- UI automation samples running on Android device.
|
||
- UI automation steps formulated and working.
|
||
- In parallel—VSTS integration of a front-end build-to-distribution workflow.
|
||
- With GIT for source code versioning.
|
||
- Front-end builds in place.
|
||
- HockeyApp for deployment in progress.
|
||
|
||
This involved a lot of setup and trial-and-error work. But we now had a good setup to bring all the pieces together and reach our final goal—achieving an end-to-end DevOps story for a front-end build with automated UI tests baked into the process.
|
||
|
||
When wrapping up the day, we formulated the goals for our second and last day of hands-on work. This time we noticed that we were able to define our goals much quicker and in more detail because we had them perfectly in mind.
|
||
|
||
The detailed goal definition for our second hands-on day:
|
||
|
||
- Upload the artifact to Hockey with the Cake script.
|
||
- Kick off UI automation steps after build is done.
|
||
- Hipchat basic integration.
|
||
- SonarQube integration.
|
||
- Think about Mock Server with Azure Functions and automated provisioning via Azure Resource Manager.
|
||
|
||
### Hands-on Day 2
|
||
|
||
Everyone on the team made sure that everything was in place for the final day and that we'd be able to put it all together.
|
||
|
||
To consolidate some functionality and keep the build definition mostly independent from the build system, we used Cake for some basic HTTP call functionalities.
|
||
|
||
In detail, we did the following, so the nitty gritty details are now officially disclosed:
|
||
|
||
- Automated HTTP calls with Cake for further abstraction.
|
||
- Using it for Hipchat notification postings.
|
||
- HockeyApp version uploads.
|
||
- Triggering automated UI tests.
|
||
- Currently works on Windows; Mac needs to wait for a fix.
|
||
- Migration of Cake build script to .NET Core for cross-platform story works out of the box.
|
||
- Upload the artifact to Hockey.
|
||
- Wrap the upload and update functionality for an artifact into a Cake script.
|
||
- Jenkins kicks off automated UI test.
|
||
- Which runs on an Android device.
|
||
- Still hard uploaded to Jenkins—no real-time build and deploy onto the device; used Cake build script to do the trick.
|
||
- Auto-deploy mock server with Azure Resource Manager template.
|
||
- Azure function collection used for mock endpoints.
|
||
- Loading and returning content of included JSONs per endpoint.
|
||
- Configuration of endpoints through direct updating with GitHub repository.
|
||
- End-to-end front-end DevOps chain in VSTS.
|
||
- From push to Hockey deployment.
|
||
- GIT for version control.
|
||
- VSTS as a build server for the front-end project.
|
||
- Notification to Hipchat with PowerShell.
|
||
- SonarQube runs on a separate virtual machine and is triggered after the build is ready.
|
||
- After a new build is done, the HockeyApp upload is triggered for this new version.
|
||
|
||
#### Building a mock server with Azure Functions
|
||
|
||
The idea is to reuse the example JSON files—which will be created for the Swagger API live documentation—to offer a mock service for the front-end development. As soon as back-end and front-end development get slightly out of sync, it's great to have all defined endpoints of an API available, even if they just return example data.
|
||
|
||
In the prototypic implementation of *FunkyMock*, this is realized with an Azure function per endpoint—configured as an HTTP trigger—and it just returns the Swagger example data as JSONs for a certain purpose—for example, a chat history or a custom user list.
|
||
|
||
```js
|
||
module.exports = function(context, req) {
|
||
|
||
var fs = require('fs');
|
||
var json = JSON.parse(fs.readFileSync('D:\\home\\site\\wwwroot\\chathistory\\chathistory.json', 'utf8'));
|
||
|
||
context.log('Output Content : \n' + JSON.stringify(json));
|
||
|
||
context.res = {
|
||
// status: 200, /* Defaults to 200 */
|
||
body: json
|
||
};
|
||
|
||
context.done();
|
||
};
|
||
```
|
||
|
||
With this approach, an easy-to-set-up mock server can be offered in very short time to the front-end development team to not get stuck during engineering.
|
||
|
||
The sources are all hosted on GitHub ([https://github.com/codePrincess/funkyMock](https://github.com/codePrincess/funkyMock)) with Azure Resource Manager templates for easy deployment and with the functions source already attached.
|
||
|
||
```json
|
||
{
|
||
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
|
||
"contentVersion": "1.0.0.0",
|
||
"parameters": {
|
||
"appName": {
|
||
"value": "funkyMockServerDeployment"
|
||
},
|
||
"storageAccountType": {
|
||
"value": "Standard_LRS"
|
||
},
|
||
"repoUrl": {
|
||
"value": "https://github.com/codePrincess/funkyMock"
|
||
},
|
||
"branch": {
|
||
"value": "master"
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
## Ask the expert
|
||
|
||
In the afternoon, we had the possibility and a bit of luck to have Andreas Pohl, a Microsoft technical evangelist, as a guest for one hour at our hackfest. Because of his strong gaming development background, he knows a lot about Unity build automation and helped us with a good Q&A session. The outcome was very valuable to the developers from RE’FLEKT.
|
||
|
||
- Unity on Windows
|
||
- How to deal with Unity on Jenkins.
|
||
- Use automation for store builds.
|
||
- The whole Unity DevOps chain.
|
||
- Service Fabric
|
||
- Best practice on deployment and CI build server architecture.
|
||
- Handling service updates.
|
||
- On push depending on branch
|
||
- At least all code is built and tests are run.
|
||
- In the future, build time can be drastically minimized by just compiling the very modified service.
|
||
|
||
## Conclusion and feedback
|
||
|
||
After three intense days, Microsoft together with RE’FLEKT achieved quite a complex goal. During the process, we did a lot of research and we weren’t afraid to get our hands onto new technologies to see how easily most of them would fit into or were combinable with already known and used technologies.
|
||
|
||
We learned a lot and managed to implement an optimized solution for the mobile development front-end story of RE’FLEKT. All of us are aware that the hackfest didn’t produce the final production-ready solution. But the awareness and knowledge is set to do the last necessary steps to finish this end-to-end chain and use it on a daily basis within the company.
|
||
|
||
Reviewing the hackfest, we summed up our impressions, learnings, and pitfalls:
|
||
|
||
- Learned more than expected.
|
||
- Did more than we expected to achieve.
|
||
- Dived deep into specific problems.
|
||
- Know solutions for specific challenges.
|
||
- Got experience with different, new technologies.
|
||
- Got connection to community.
|
||
- Microsoft showed alternative solution paths.
|
||
- Value stream mapping was super helpful for getting a perspective on where to head in the future.
|
||
- Would have been helpful if the technical advisor of Microsoft had taken care of sketching during the VSM session.
|
||
- Saved time and would have gone much smoother.
|
||
- Team can focus on the "thinking" while someone else does the sketching.
|
||
- Whiteboard/Surface Hub would have been better than a piece of paper.
|
||
- Everybody can stand and draw in collaboration.
|
||
- Getting more perspectives into the whole picture.
|
||
- Much more drawing canvas!
|
||
- Good to have the workshop outside of the customer’s office.
|
||
- Really be able to focus on the tasks.
|
||
- Focus on hacking and take time for it.
|
||
- Small room is good to be able to start a conversation at any point.
|
||
- See what others are currently working on.
|
||
- Room with different ways of seating works well.
|
||
- Big screen mandatory.
|
||
|
||
## Further steps
|
||
|
||
Microsoft offered further guidance in the form of an additional hack day if desired or necessary for the back-end story. We did a VSM together to define the goal, but attention to detail is always key. Additionally, Microsoft offered help with advice and guidance if the front-end story gets tricky at a certain point–especially with the Unity and UWP story.
|
||
|
||
## Hackfest impressions
|
||
|
||
<img src="{{ site.baseurl }}/images/reflekt/team_impression.png">
|