Building a reproducible AWS serverless Android DevOps flow — 1

Photo by Quinten de Graaf on Unsplash

SoftChef is the only software partner with AWS IoT Labs in Taiwan, from the cloud to the ground, we build and power IoT applications on rich serverless architecture experience and expertise for our customers across various fields like energy, manufacturing, smart city, etc.

Apply serverless approach to IoT project is the top priority at SoftChef, because we know how tremendous its value our customers can benefit from.

I’m an Android developer on the mobile team. Serverless services seem not so related to an Android developer in our day-to-day development. But once you have a chance to try to build a simple backend API to be invoked by the mobile side, you’ll find serverless services provided by those cloud giants can save you lots of time and effort even money:

1. CLI commands to deploy is very fast.
2. Tools let you focus on logic and functions that you want to achieve, not the development environment.
3. Cost is execution-based, which means charge depends on your usage.

All these traits above you can see on Google firebase functions(Or Google cloud functions)、AWS Serverless Application Model, and others.

IoT applications are hard to replicate due to its nature. One domain-specific knowledge is very different from the other, and resources deployed may not be in the same AWS region, too. Still, the same thing is they all need to do unit or integration tests before we ship to our customers.

The DevOps flow is where serverless begin adopted at SoftChef mobile team besides API. Create a serverless DevOps is not enough. We need a reproducible way to deploy the entire infra from applications to applications, and it has to be automation to save our time to deal with more urgent things.

That’s what I’m going to share in this post, and since we are working closely with AWS, we’ll use AWS services to build the flow. If you’re familiar with AWS services, the first thing that comes to your mind would be “Cloudformation,” wouldn’t it? If not, don’t worry, we’ll demonstrate its usage later on.

I assume you have a basic understanding of AWS, like how to provide a policy and role to access a service.

Let’s see a picture to illustrate the flow:

Serverless CI flow we’ll build in this post.

We use Github to manage our code, so the very beginning starts from pushing code to the remote branch(AWS provides S3 and others as options), ends with Device Farm test run finish.

After someone pushes code to Github, the AWS Codepipeline will detect our source has been changed, hence to pull the source code to S3 bucket to be next pipeline stage’s input, which is CodeBuild on the top-right corner of the picture.

Then inside the CodeBuild, it’s a Linux container managed by AWS, we’ll do some Android stuff like a serial build and test Gradle command. Similar to the previous step, if everything’s okay, we assemble the Android code to be Device Farm’s input for instrumentation test.

Devive Farm is a service for testing the mobile app on the real device, and AWS manages these machines; it charges based on your testing execution time(AWS provides 1000 Free testing minutes). Contrast to build a pool of devices in your company, and you don’t need to set up a device management system, or need to maintain or update the latest model on the market both Android and iOS platform.

We’ll do Android instrumentation in this post, but other popular options like Appium, Calabash, and more are available.

When the pipeline starts, we use AWS CloudWatch event to trigger a Lambda to expose the pipeline’s execution state within a Slack channel until the test run finish.

This is what the flow will output in slack CI bot

The last thing before we look into some scripts, the essential service is not introducing yet — AWS Cloudformation.

Infrastructure as Code — AWS CloudFormation provides a common language for you to describe and provision all the infrastructure resources in your cloud environment.

If we could find a way to define all the services our DevOps will use in JSON or YMAL files, then we can reproduce the flow, deploy it over and over again within minutes.

For instance, this is how to define a Lambda:

Line 5 Handler property defines a start point that can be invoked by AWS Lambda and line 7 Code property indicates the CLI tools where to find all the implementations and its dependencies.

In the next post, we’ll see more scripts like above, and I’ll upload a sample project. The sample project contains a simple Android project and some functions written in Python.

You just have to install AWS CLI , Python toolchain, a basic understanding of Python like me, and of course, a working AWS account😅.