devops refers to a set of well-known practices for automating software deliveries. by design, devops allows for easier maintenance and updating through continuous testing, code quality improvement, and feature development. one of the primary objectives of utilizing devops is to facilitate developers to perform quick, reliable, and automated publishing without any human interference – a feature known as continuous delivery. this document explains how you can implement devops with android apps.
robust continuous integration is essential for implementing continuous delivery. although continuous integration is readily available within the android environment, let us review it again.
all android apps must support continuous integration. in fact, continuous integration provides modern app development with several significant advantages, such as:
build automation: with this feature, you no longer have to say "but i can successfully build it on my computer." instead, you can build apps wherever needed.
proactive debugging: app building after each push ensures that you can detect potential errors early.
testing continuity: this feature enables continuous testing.
continuous packaging: this feature allows you to eliminate human errors during binary code packaging.
accelerated publishing: simplifies publishing as you have confidence in every build step.
improved confidence: you can trust your code and reduce unexpected errors.
before implementing continuous integration, you need to prepare an integration server such as jenkins or travis. the steps involved in the continuous integration process is as follows.
a job starts once the push in the source code repository (such as git or svn) is complete. this job will view development channels, compile code, run unit tests, and package and debug the apk.
after the initial job is successful, the next job starts. this job runs integration tests (through espresso or robotium) and ensures the user experience quality by reproducing scenarios and checking image content. to do this, you can utilize a connection device (this could be tough if you have difficulties obtaining a ci server), genymotion, or the latest built-in simulator supplied with android studio 2.0 (recommended) for operation.
a separate job will run a code measurement (such as through sonarqube) to monitor code quality. for example, you can run this job every day at midnight.
finally, run another job after pushing the master branch or publishing the branch. this job will compile the code and then generate and publish the apk.
that is it! as you can see, the entire process is not only simple but also ensures the implementation of all the advantages of continuous integration.
testing is very important since it is the only way to prove that the apps run as expected. there are plenty of tools that can help you write a great test code, but you still have to make an informed choice.
also, you must be practical when selecting function libraries for integration into the app. in fact, you must understand that function libraries with higher test coverage facilitate app testing. this is because these libraries take into account not only testing accuracy but also ways to improve development through testing (imo, okhttp, and retrofit are all good examples.)
a function library like dagger can also boost testability. in fact, it forces you to follow the "single responsibility principle," in which the code is separated appropriately to simplify testing.
now that we are familiar with implementing robust continuous integration, let us look at an example of the upgrading process.
trainline eu releases a new version of its booking app, captain train, every six weeks. currently, it is in beta phase, with support for four locales, four language environments, and three types of devices (phones, 7- and 9-inch tablets). the developers create release notes, use the rollout feature, and upload 72 screenshots (6 screenshots 4 locales 3 types). it has an android wear companion, currently in test phase.
this upgrading process takes a long time to complete. recently, the firm made serious attempts to automate the process to accelerate version releases whenever possible. furthermore, this automation eliminates human errors and ensures consistency among different released versions. developers can control the entire release process, while the marketing team needs cooperate with them to integrate changes into the different released versions.
since developers cannot control every aspect of android, google has to provide them with the necessary tools. for instance, google provides developers with http apis so that they can easily interact with the google play console. also, google provides clients with various development languages such as java (this is a must), python, and ruby.
this document mainly describes the java client as it is the best-known client for android developers.
this process involves two steps: configuring the console to enable the client and then discovering the apis. configuration is the hardest part when you try to establish a connection with google.
first, you have to create a project in the google console, that is, if no projects are available. next, enable <code>google play android developer api</code>.
once done, create a credential of type service account key.
next, create a <code>service account key</code> type certificate.
complete the table and download the json certificate file. during the process, you need to save the following three values: <code>private_key_id</code>, <code>private_key</code>, and <code>client_email</code>. save the value of the <code>private_key</code> to its <code>secret.pem</code> file.
now, the developer console is ready. next, move to the second console.
connect to your project. authorize the email address that you entered in <code>client_email</code> of the json file in <code>service accounts</code>.
that is all the required steps. now, you are good to go!
you need to configure the access interfaces through the java client. to do this, create a java project in the publisher and add the following dependencies (available in maven central):
compile 'com.google.apis:google-api-services-androidpublisher:
v2-rev20-1.21.0'
then, create a new <code>androidpublisher</code>. to do this, first update <code>googlecredential</code> with the following information: the client connection, the json factory, the private key id that corresponds to <code>private_key_id</code>, the account id that corresponds to <code>client_email</code>, the <code>androidpublisher</code> range, and the key file that corresponds to <code>private_key</code> and contains private key information.
then, create an <code>androidpublisher</code> instance using the app package.
androidpublisher is the main entry to google apis. it provides the "edits" method that allows you to modify the data that you want to obtain from the console.
to create a new version, you must start with the "insert" request and save its "id", which you will use during each subsequent call.
now, you can begin modifying console data. for example, you can change the ranking:
you can also upload a screenshot:
lastly, you can upload an apk:
finally, you must submit your version. in fact, google records all your change requests, but it does not save them unless you have submitted the version. you should verify those changes before submission.
edits.validate(package, id).execute();
edits.commit(package, id).execute();
as you can see, you can use the id that you retrieved at the beginning of the code as the transaction id. by calling <code>insert, update/upload</code> for your changes to start a transaction, you can then <code>validate</code> and <code>commit</code> those changes.
by using such tools and processes, you can release new versions in the production environment simply by pushing the master branch. such arrangement provides you with high levels of simplicity, efficiency, and reliability.
obviously, the method that applies to one situation does not necessarily apply to all teams, companies, and apps. as such, you must determine an appropriate method based on your needs and teams' dynamics. nonetheless, continuous delivery should be the common objective for every development team.