Continuous integration for mobile
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 46 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/47189 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Continuous integrationMobile WebBuildingDistribution (mathematics)Logic gateBitLecture/Conference
00:17
Continuous integrationDistribution (mathematics)Level (video gaming)Android (robot)BitLecture/Conference
00:35
ACIDRepetitionDisintegrationError messageContinuous functionSoftwareContinuous integrationContinuous integrationWater vaporSoftware developerINTEGRALWeb 2.0Linear regressionDifferent (Kate Ryan album)Software testingError messageMultiplicationLecture/ConferenceMeeting/InterviewComputer animation
01:15
Server (computing)CodeSign (mathematics)Software testingLevel (video gaming)Latent heatSoftware developerWorkstation <Musikinstrument>Cartesian coordinate systemMeeting/Interview
01:42
Continuous integrationSoftware testingCodeDistribution (mathematics)Cartesian coordinate systemSoftware testingBitDistribution (mathematics)Continuous integrationMobile WebProper mapComputer animation
02:06
BitDifferent (Kate Ryan album)Service (economics)Physical systemSoftware testingMeeting/Interview
02:24
MereologyPoint cloudGoodness of fitService (economics)Continuous integrationLecture/Conference
02:41
Continuous integrationPoint cloudFreewareSource codeConfiguration spaceDisintegrationService (economics)Open setFreewareSelf-organizationOpen sourceProjective planeMultiplication signPoint cloudFeedbackConfiguration spaceSinc functionCodeService (economics)Internet forumDefault (computer science)ScalabilityLine (geometry)MultiplicationINTEGRALWebsiteWell-formed formulaCuboidComputer fileMeeting/InterviewComputer animation
03:38
Classical physicsSoftware testingPoint (geometry)Limit (category theory)Game controllerComputer hardwareMeeting/Interview
04:09
Plug-in (computing)Unit testingChainVirtual machineLecture/Conference
04:45
Open sourceMatrix (mathematics)Metric systemDifferent (Kate Ryan album)Process (computing)Software testingComputer simulationVirtual machineEmulatorInternet forumGoodness of fitComputer animation
05:21
RepetitionProcess (computing)WordLecture/Conference
05:49
Task (computing)Parallel computingElectric generatorWeb 2.0Hydraulic jumpTraffic reportingPoint (geometry)Branch (computer science)Software testingTemplate (C++)Normal (geometry)Different (Kate Ryan album)FeedbackDistribution (mathematics)Computer animation
06:46
Error messageLie groupSoftware developerTemplate (C++)LoginInformationMeeting/InterviewLecture/Conference
07:07
Continuous functionBuildingFeedbackSoftware testingMathematical analysisFluid staticsCodeLogic gateConfiguration spaceAutomationCodeMereologyBitComputer animationProgram flowchartLecture/ConferenceMeeting/Interview
07:44
Software testingFluid staticsMathematical analysisCodeMereologySoftware testingProjective planeLibrary (computing)Service-oriented architectureComputer animation
08:06
CASE <Informatik>CodeProjective planeGame controllerSoftware testingBitArithmetic meanTotal S.A.Traffic reportingReal numberMeeting/Interview
08:56
Continuous functionSoftware testingMathematical analysisCodeFluid staticsMathematical analysisCodeAutomationPlug-in (computing)ProgrammierstilFluid staticsMultiplicationComputer animation
09:13
Projective planeCodeAndroid (robot)Point (geometry)FeedbackNumberDecision theoryHookingMathematicsProduct (business)EstimatorMeeting/Interview
10:08
Projective planeAndroid (robot)RankingCodeCartesian coordinate systemFunctional (mathematics)Arithmetic meanSoftware testingUnit testingLecture/ConferenceMeeting/Interview
10:43
Continuous integrationSoftware testingWeb pageVideoconferencingSoftware frameworkAndroid (robot)Execution unitEmulatorPoint cloudDisintegrationService (economics)Integrated development environmentHookingThread (computing)Software testingOrder (biology)Multiplication signCartesian coordinate systemFacebookEmulatorUnit testingScripting languageSoftware frameworkBitINTEGRALRight angleAndroid (robot)Computer animation
11:57
RepetitionSubsetSoftware testingINTEGRALLecture/Conference
12:11
Product (business)Software testingWeb 2.0Goodness of fitWeb pageServer (computing)ResultantExpressionDigital rights managementMeeting/Interview
12:49
Bit error rateVideoconferencingSoftware testingDifferent (Kate Ryan album)Object (grammar)Cartesian coordinate systemCloud computingINTEGRALWeb browserAndroid (robot)Computer configurationNumberMeeting/Interview
13:45
Software testingINTEGRALService (economics)Unit testingResultantLecture/ConferenceMeeting/Interview
14:15
Bit error rateCodeMaxima and minimaSoftware testingContinuous functionBlock (periodic table)Execution unitLoginTouchscreen
14:35
GoogolFeedbackTraffic reportingWeb pageMereologyPoint cloudMultiplication signUnit testingResultantSubsetInformationSoftware testingSelf-organizationLogicExecution unitOverhead (computing)Meeting/Interview
15:29
Different (Kate Ryan album)LaptopDistribution (mathematics)Virtual machineLecture/Conference
15:45
GoogolHookingDistribution (mathematics)Scaling (geometry)Service (economics)Different (Kate Ryan album)Multiplication signData structureLecture/ConferenceMeeting/Interview
16:06
Parameter (computer programming)Distribution (mathematics)MathematicsGoogolPoint cloudSoftware testingService (economics)DisintegrationFormal languageGraphical user interfaceLevel (video gaming)Branch (computer science)MathematicsData storage deviceSelectivity (electronic)Template (C++)MultiplicationPhysical systemServer (computing)Scripting languageCuboidSpacetimeVirtual machinePlug-in (computing)Distribution (mathematics)Software testingService (economics)BuildingGoogoloutputComputer animation
17:30
GoogolBeta functionIntegrated development environmentPoint cloudData storage deviceSoftware testingGame controllerStability theoryAlpha (investment)Scripting languageWeb crawlerMultiplication signProduct (business)TouchscreenMeeting/Interview
18:35
TouchscreenPasswordLecture/Conference
18:53
BuildingMultiplication signInformationMeeting/Interview
19:14
Software testingMultiplication signWind tunnelLecture/Conference
Transcript: English(auto-generated)
00:06
I hope you all enjoy Droidcon until now, as much as we are. We are here to talk about continuous integration for mobile. We will deepen in more advanced topics a little bit, like build pipelines, quality gates, and distribution channels.
00:23
I am Thanos Karpusis, I'm Senior Android Engineer for Babbel, and with me on stage is Sven. My name is Sven Kroll, I'm a Mobile Quality Engineer for Babbel, and as Thanos said, we are going a little bit deeper on the topics, but first we start with a short introduction to continuous integration,
00:41
and what's best for this than quoting Martin Fowler. Continuous integration is a software development practice where the members of a team integrate their work frequently, usually each person integrates at least daily, leading to multiple integrations per day. Each integration is verified by an automated build, including the tests,
01:00
to detect integration errors as quickly as possible. So having now a small quote of this, we have to think about the differences between the web world and the mobile world, because mobile is quite new, so there are differences and big differences. So one thing is definitely the infrastructure. You have to provide a good infrastructure for your tests and for your build,
01:26
because you have to think about devices, which devices have to be tested. Also, the staging servers are totally different, so it has to be sometimes coded into the application, it has to be a testing flavor for pointing to a specific staging server.
01:41
You have to do code signing for the applications, and of course, the testing is totally new. It's maybe two or three years ago, bigger and bigger, but it's still a problem to do proper testing for mobile, and integrating this into a continuous integration is also always a bit complicated. Also, the distribution, you have to provide APKs,
02:03
you have to make it possible that the people care, or your testers, your stakeholders can use them properly. So talking about this, we are going a little bit deeper in different systems we are using, we used to use a bubble, and we are still using. So first, we're starting with Travis CI.
02:22
So we start working with Travis CI, which is a continuous integration as a service, pretty much. It's a Berlin company, and that's a very good part of Berlin. It's really easy to use, and that was the best part of it. It's a hosted cloud solution.
02:43
It's free for open source projects, so if you're a small team, if you're doing something open source, that's the way to go. But at the same time, you can have premium accounts if you are a bigger organization and you want to keep your code private. The configuration is super simple. It's just one file, just five lines more or less
03:02
that you can find on the website, or a lot of forums provide some more customizable configurations. And then it gives easy integration with multiple services out of the box, Atlassian tools, GitHub, and all the things that you need to get,
03:21
all the feedback right away with the tools that you are already using within your team. And of course, since it's a cloud solution, it's scalable by default. We have been using that for more than a year, but in our case, for mobile,
03:41
we wanted to have control over our hardware. We wanted to be able to add different devices for our tests. We wanted to play with some more exotic tools like watches and other channels. So at that point, Travis, it was a limitation for us. So we tried to do something that we controlled more,
04:01
and we went back to the classics, back to the basics, and taking them to me. And yeah, we switched recently to Jenkins, which is, I think, well known. It has a lot of plugins. You can integrate most of the stuff you need by plugin. There are plugins for displaying the unit test coverage,
04:22
where we talk about later. It's also scalable because you can self-host it, you can open nodes, you can open everything you need, and you can have a specific node for a specific purpose. So you can have a node for building stuff where the keychains are, which is really secured.
04:41
You can have a node just for building infrastructure. You can actually spawn new virtual machines with Puppet and with Vagrant. And this makes it also really flexible, and you can have, in these virtual machines, you can also have different simulators and emulators
05:01
started for different test purposes. It has high flexibility on the artifacts because you can store it on the device, you can hand them around. You have a really cool permission matrix, which means you have a job which is publishing to Google. It's not a good practice that everyone can publish to Google.
05:21
You have a job where the QA can issue their own builds, which leads to really less work for the developers because they don't have to go to the QA and talk to them. The QA can issue their own builds, and this makes it really, really flexible. And this was one of the biggest reasons, besides the possibility to update everything as you want.
05:45
And the next step I'm talking about are build pipelines, which means it's really cool working with Jenkins to build pipelines, especially for mobile, because you want to have fast feedback.
06:01
You want to know what's going wrong really fast because mobile tests usually take longer. You don't have jump points like in the web world. You want to have really fast information. You want maybe to paralyze things which are taking longer so you can paralyze different steps of testing.
06:22
You want to have instant reports of what's going wrong, what's the problem. And one really cool thing we implemented above are automated build pipeline generation. This means we have a master pipeline for the release, we have a master pipeline for the distribution, we have a master pipeline for the normal develop,
06:40
and it's possible to just when the developer opens a new branch that everything gets created out of those templates. How does build pipelines look like? So when the development team checks in, everything gets triggered, and there are logs for everything you need. So it's a really cool way to get the information quickly
07:04
and as exact as you need it. So the next topic will be quality gates. Okay, so as we mentioned, we are not talking so much about the configuration and setting up the CI. I guess everybody can spend like a day and set it up.
07:23
Quality gates is the first, a little bit more advanced part. It's not just building an APK, but going one step before that in the process and ensure that your code is of high quality enough and ensure that it could be expandable and maintainable in an automated way.
07:41
Of course, we have the first step. The easiest step is also provided by the Android tools is using some linters, going with ProGuard, Minify, and make sure that you don't have garbage in your APK. You just have the resources, the libraries, and the methods that you need, and ProGuard and linters take care of that. The second part is your test coverage.
08:02
We believe that it's one of the most important KPIs for the health of a project to know, to have automated tests, and the easiest way to measure that is play with tools like Xacoco and make sure that you're keeping very high test coverage on your project. It's also really easy to set up that usually takes
08:21
less than half hour to set it up and plug it in with Jenkins in this case. In means of Travis, usually it's a little bit more complicated to get the reports as you want, but with Jenkins you have total control and it's really easy to play with. Style guidelines, that's something not so important for most teams, especially if they are small
08:42
or if they're using the ID code styling to get there, but if you are talking for bigger teams, if you are talking about teams that are distributed all over the world, you want to ensure that your code looks exactly the same, not based on your developer effort, but with automated tools,
09:00
also provided as plugins for Jenkins, you can just pause for them, there are multiple of them, you can find the code style that you like most and apply it. And now the most important of all is static code analysis. So we are great developers, we are building great products, but we are working fast. We need to have a point of truth
09:21
that we verify that our code is of high quality. There are multiple tools, we are playing with SonarQube solutions in Babel and with Jenkins it took us, okay, we had a few troubles setting it up, it took us like a week, and still we have problems with that, but we get a lot of feedback based on how clean is our code,
09:45
how much code is duplicated within our project. We are able really fast to make measurable estimation and make decisions on how to move forward based on the numbers on that. Again, SonarQube provides a lot of tools for Android projects.
10:05
It's kind of hard to hook it up with Jenkins, but you get it there. I think the problem is mostly the Android projects and not so much Jenkins, but we had some problems, but now it's working and having that the next step after you make sure
10:22
that your code is of high quality, you need to make sure that your application still functions as you expect it to be. And that means we need to have some testing and yes, most teams have dedicated QA departments, but that doesn't mean that we should avoid the automated test. That's the basics.
10:41
We start with unit testing using Robo Electric Android Test Framework Espresso and what gets interesting is how you hook them up with your CI in order to work with both physical and virtual devices. Also very simple for Jenkins to do so.
11:00
You just plug in your couple of devices or you have a small script to start your emulators from the CI. And maybe the one thing that you need to focus is to put a bit more intelligence on your CI in order to keep the devices not just physical but also real. That means start some other applications.
11:20
Facebook is a good example. It takes a lot of resources, Facebook Messenger for example, to see how your application really behaves in a real device. The trouble with CI is that we have a really lab-like environment. Everything is so clean. The emulator is usually completely fresh every time that you start them. Put some effort on your CI infrastructure
11:42
to make the devices feel real. It doesn't take that much time. Even run a monkey test that is provided by the Android Studio just before running your test or right after. It will give you way better feedback. And the unit testing and integration test is just the first step. We also have acceptance test that Zman will talk about.
12:01
As I said before, acceptance test is the next step which might be also paralyzed. There are tools out there which handle a lot of acceptance tests like Appium which we are using at Bubble, Colorbash or Espresso. You can have really meaningful tests and also really good test results
12:21
for the developers, for the stakeholders, for your product managers, for basically everyone. You can even put it to some monitors at your workplace so everyone can see how great you proceed, how good your test coverage gets. And you can have, as I said, like HTML pages
12:43
published from the Jenkins to web server or on the Jenkins itself where everybody could see how it looks like, how many tests are there. If they are failing, there are screenshots or even videos where the developers or other people can see what's going on. Maybe there's a notification too much
13:01
or there is something wrong in the navigation through the application. So this makes it really cool that it's automated and you get it on your CI and really every stakeholder you need can get it. And the next big step is the integration with the different cloud services.
13:20
So we all know there's a big fragmentation in Android. So there are cloud services out there like TestDroid, like TestObjects, like BrowserStack, etc. So there are a number less of options which you can take and which you should consider. For example, if you're seeing that your application
13:43
is crashing on a specific device and you don't want to have all those devices in your house, you can use those services to do your integration tests from the Jenkins. They get sent to those. I think there was a talk in the bar camp about this. There will be also talks about unit testing.
14:02
So we don't dig really deep into this, just that you see what is possible. And a test result could look like this. So you see what's the result, or it's red, what's going wrong. So you see things are failing.
14:20
You get a screenshot, you get everything, what you can think of. Whoops, what's going wrong? So you as a developer could see what's going wrong, where I can do it, and you get the information as fast as possible that you can fix what's going wrong. And now we have already talked about so many different aspects
14:40
that provide a lot of feedback. We are talking about reports that are going for many pages. The important part of how you use the CI is that it actually can handle this information and not spam you. You don't have enough time to go through all the results about your linder. You don't have enough time to go through all the results from your cloud testing.
15:00
You can add all this logic to your CI. You can only have alerts when it's meaningful for you and have different alerts for the different people that are working within your organization for that reason. For example, QA may care about an acceptance test that failed. You may care just for the unit tests. Other people, your stakeholders, may care that the build is ready to be published.
15:22
The CI can take care of all this overhead that until now was handled mostly by developers and QA engineers. And last but not least, I think it's the most important actually is distribution. It's typical for all of us to, at the end, have a build in our own machine, in our own laptop,
15:42
and then push it to the different distribution channels. It's fine, but if you are looking for, again, for teams of this scale and they provide multiple builds all the time, why handle it yourself? The CI infrastructure now is really simple to hook up with all the different distribution services.
16:03
Like, we are using Translytics, for example, and actually it's super easy to hook up with Zengings because you don't really do that. You're using Gradle and the SDK provided by them. So that's done out of the box, both for Travis and Zengings as well. Travis has a few problems with the artifacts provided
16:21
because you need to have some kind of your own storage system use either S3 or some kind of your own server to store all the artifacts. Zengings is in your own machine. You can use this space to hold all the artifacts. Then the thing that you can do about distribution and your CI server is add a level of customization for its build.
16:44
You can either have some templates that do it all out of the box or you can give your input while you set up a build. So you can select testers. You can select everybody who you want to get the build. You can form your change log.
17:01
You can use actually multiple plugins for that or write your own script, taking the history from your Git log or write it yourself. And also select stuff like branches, which is pretty easy, or if we are talking about a multi-flavor app, set which flavors and how.
17:21
All this stuff for any of the CI servers out there usually takes less than a half hour. And then the most important thing, how we publish to the Google Play. Yes, a lot of people want to have still the control over it, but now last week Google announced the Cloud Test Lab
17:40
that works with alpha and beta channels of the Google Play. There is also a very simple API to help you push your APK directly to the store. Let's not talk about the production environment, but let's just focus on the beta channel. Right now, not right now, in a couple of weeks
18:01
they said that they will make it publicly available that an automated monkey test will run every time that you push something to your beta channel. Why not using it once a day on your nightly builds to make sure that the Google crawlers are able to verify that your build is stable.
18:22
Again, the provided API by not Google really, yeah, it's by Google, but also has already a lot of scripts ready for you in the community. It took us ten minutes to integrate it with our CI to have this, you have a blue screen of death.
18:41
Let's see Sven's password. And again, you just spent less than an hour to set up all these things. So we talked about five add-ons to your basic build. Unfortunately, we don't have enough time
19:01
to get into deep details about them. We just mentioned what you can do. We are available for you to give you more information on how we did it, which tools we are using. But go ahead, play around. The CI is not just to build something or just run tests. It's so much more things that you can do with that.
19:25
We thank you for your attention and if you have any questions, I think we have enough time for work. We have. We have. Thank you, Thanos. Thank you, Sven.