DEV Community: Maciej

You shouldn’t take AWS Pearson Vue Online Proctoring exam and here is why

Maciej — Tue, 13 Dec 2022 10:54:54 +0000

Some time ago I took AWS Architect Associate exam. I’m already a holder of a AWS Developer Associate certification so I expected no issues. I couldn’t be more wrong!

I will tell you what to expect, what the policies are, what surprised me and why you should avoid online proctoring exam, if you have alternatives.

What you will be obliged to do before even starting an exam?
Be sure to run system test. You should do it in the same room, with the same devices and WiFi that you will use during an exam. I have couple of WiFi networks which can be switched dynamically so I checked all of the options beforehand. Think what could go wrong because something most likely will.
Read the online exam policy, that’s the best one thing you can do. And don’t be scared of it at all. I won’t elaborate on it. I will describe what wasn’t there later in this article so you will be well-prepared!
Disconnect all external devices from your PC/Mac/laptop. Remove them from the desk. That includes external monitor if you’re using MacBook or Windows powered laptop. Any Linux powered devices are strictly prohibited. I ended up disconnecting and removing my monitor 10 minutes before an exam! My fault.
You have to be in a closed, well-lit and calm environment. They need to see closed doors as a part of “room verification” process. No one can enter, no one can talk, remember!
What was surprising since it wasn’t written in the policy?
The recommendation is to start 30 minutes (!) before exam scheduled time. But it isn’t written why. It’s because entire verification process takes eons. In my case it took 1h. Sitting and waiting was the major part of it. Although I saw it could be worst than that. One must be ready to spend 140 minutes of exam alone. Additionally, there will be couple of minutes on pre- and post-exam activities. Finally, you would have to spend from (promised) 15 minutes to 1h (or more as few people shared) on verification process. That adds up to almost 4h spent in one position in front of your computer. Remember, while verification process and exam is happening you cannot stand up, you cannot go to bathroom, you cannot drink nor eat, you cannot talk and you cannot look into window. Talk to your partner and/or roomies and plan for it. You have to make your room a Temple Of Silence for a time being.

As I mentioned, they will verify your identity. That’s understandable and would also happen on-site. The verification process can be done via your smartphone, for example. Also, a proctor might try resolve technical issues with an exam by calling your phone. But, according to policy, you’re not allowed to have phone within your reach. Nor any smart devices. If someone would call you — exam could be cancelled. I recommend having your phone on silent mode, at least 1,5h meters away but with visible screen — so you know when agent is calling (strange, unknown and international number) and you won’t end up with cancelled exam because you picked up a call from your boss/partner/parent/friend.

Policy also states that you need government issued ID card in order to identify yourself before an exam. During the verification process I was able to choose from driver license or passport only. ID card is not an option and that was a big surprise to me. I had to find one of the approved documents very quickly. Don’t do it to yourself and prepare ID card and the second document beforehand, just to be sure.

So, what really happened and why I’m simply disappointed?
As a part of verification process I was contacted by a polite agent.
She checked my workspace using my camera view, so, what’s behind
and in front of my desk, my hands and wrists for watches and cheat sheets.
All good! Good to go!

Everything was fine until she disconnected from the chat and remotely triggered an exam. My entire screen went black instantly.
The only thing I was able to see was an overflow menu with the following items: Pearson logo, chat, whiteboard and my camera view.
I waited around 10 minutes hoping for exam to be loaded. Then, I clicked ‘chat’ icon — instantly — entire application froze. I waited for some time hoping it will ‘unfroze’, unfortunately, it have not happened. I had to force restart entire device.

I’m running MacBook Pro with quad-core CPU and 16GB of RAM. You can be sure it’s enough. I’m running Android Studio, Docker and much more on a daily basis. Additionally, I was at 300Mbs fiber backed internet connection. So, I kinda blame Pearson software.

How to resolve broken exam situation?
You need to go to AWS dedicated Pearson help center. Since my country don’t have dedicated Pearson phone number I spent more than 1 hour waiting for online assistant. It took around 15 minutes to open a case. Now, I need to wait from 3 to 5 business days to resolve the situation. The entire process is “very corporate” if you understand what I mean. It’s slow.

Take exam on site!
Take the above mentioned points into consideration while scheduling an exam. It’s all understandable but it’s quite limiting comparing to taking an exam on site. On site you can go to bathroom, drink, you will have a piece of paper to work on, you can relax a bit. If you’re able to schedule on site I recommend it. I won’t do online exam again unless #covid19 will force me to.

Obviously, shit happens. I’m not furious nor mad but I want to warn you what may happen, how reality looks like, so you’re not disappointed. Every student spends a lot of time beforehand in order to pass an exam — it’s a bit frustrating when technical issues gets in the way.
I understand software sometimes is not functioning as expected as I’m also introducing issues from time to time. All software engineers do.
Simply, if I would have a choice between on site stable exam environment and unstable, unpredictable software — my choice is obvious.

What was your experience with online proctor exam? Let others know in the comments!

How to start writing reusable components for Android apps?

Maciej — Sat, 27 Aug 2022 19:03:00 +0000

How to start writing reusable components for Android apps?

The purpose

For anyone, like myself, interested in building custom, reusable view components for an Android app. And those who had problems with finding good guidelines on the topic.

I will provide the basic reasoning behind architecting custom reusable views. There won’t be implementation details (code) for many reasons,
one of those is my trial to focus on the concept rather than technicalities.

Anyway, I hope that after reading this article you will be able to apply those principles to any interface architecture pattern such as MVP, MVC, MVVM
or MVI.

The first part says why and when adapt such technique.
You can jump to the second part for the list of recommendations.

First, ask yourself a question: Do we need reusable components?

IMHO you should be a part of a bigger, long-lasting project to consider doing so. I understand it’s hard to draw a line between MVP/short-term
and a long-term project sometimes. It is sometimes also hard to let go of technical nicety such as custom views but please be mature to do so.
The following list should help you making a decision.

Definitely a hard nut to crack. via meme generator

YAYS

If you’re in a flexible environment where design decisions are done based upon many perspectives(not just your own) so you can pitch for good UX/UI.
If you see one (or more) view is used (will be used) in many places (reused). Plan for it. Those views should have fairly similar UX/UI to serve as a reusable components. Otherwise, reusing them will be challenging. Again, pitch the team to sustain consistent user experience.
If your teams plans to build extremely custom view like karaoke,
piano keyboard, fancy animated overlays, etc.
Finally, I have not tested this theory but IMHO if you’re bored and you feel like making an old legacy project interesting.
Since writing reusable components is like writing complex new features.
If you’re able to deliver business value by creating such components.
If your team plans major refactors and you have time to just play with the product.

NOPE

POC or MVP cases. Although, MVP cases could be a good playground.
Small, simple app cases. There are situations where you know an app will be coded once and left as is. BTW Consider going cross-platform with those. Again, nice playground.
An inflexible environment. Design system gave to you up-front instead
of being discussed with all parties involved.
Your codebase is not ready to handle reusable components.
Please see Prerequisites *section at the very end for few tips.
In this case you might have to put some work beforehand in order to *enable reusable components.

Brace yourself! via meme generator

Ok, so now you’re sure. Let’s go with recommendations!

1. Custom views

It could be quite obvious for some and not necessary for some others
as I noticed. Deeply research the case of custom views first and try to imagine them as reusable and self-contained components. Don’t be afraid.
There are plenty of materials to learn how to create simple custom view.
Remember, it doesn’t mean you’re responsible for rendering everything yourself. It doesn’t mean you have to create those components from scratch neither. It will be the better and simpler version of what Fragments suppose to be.

Think of a custom view as a container (f.ex ViewGroup like FrameLayout)
for other components grouped together to serve one purpose.
For example list of results used in couple places, part of product detail screen, or maybe just a grid product item used on different screens of your app,
or a search-bar and corresponding list of results. In the Toolbar/bars case
be careful. We had a lot of work with extracting Toolbar out of custom view after we realised Toolbar should be a separate, reusable component itself.
The important parts are reusability, testability and independency.
Decouple your view and controller from everything else, more on this shortly.

I would suggest to read about Atomic Design in order to imagine the building process better. Basically, think of an any widget like button or label as a basic building block for bigger component. No matter if custom or native one.
Then imagine your custom, reusable view (imagine now list of results with reload button) and just compose those two views together. Handle composed views through your view controller or/and communicate through business logic (f.ex in a reactive way but that is not an only option) and you’re good to go.

Please remember, it is complex stuff. Probably the first place you will choose for refactor will be the wrong one. It was the case in my case.
My tip would be to go with the simplest view first.

DON’TS
Fragments inside “main” fragment.
Parent-child relation between views or view controllers.
Toolbar as a part of custom view.
Navigation bottom bar (iOS Toolbar) as a part of custom view.
Coupling. Activity/Fragments does setup for view.

DOS
Custom view that serves one purpose.
Activity/Fragments just render/show/hide view.

2. Use platform-native components as much as possible

Speaking of custom views, don’t go fully custom if not forced to.
Reusing existing components and widgets just makes your life easier
and enables you to work on actual, unique to your app business value. Work alongside with product/UX/UI/your own team to build native-first design systems. In most cases there is no need to go completely custom
and I’m sure your client is more than happy to get rid of an animation or fancy screen transition just to get business value on the place.
Ours clients are #trueStory.

What do you mean by native components?

Google did a great job introducing Material Components — guidelines with the corresponding implementation you can reuse in your application.

You could also consider not-views related components like Navigation Component which plays nicely with bottom nav bar f.ex. and could simplify your codebase.

You should take a look on how to compose and reuse themes and styles for your application, here is a presentation from Googlers on the topic.

But in the end just reuse old, good widgets and layouts to get things done.

3. Use modern app layer (view layer) designs patterns

Yep, and not only for the app layer. Plenty articles on that matter. I recommend you to read Hannes Dorfmann’s story on MVI since a lot of useful concepts and ideas are there. He elaborates on topics such as how to organise, test, reuse and maintain your code which is not a part of this article but those two topics are strictly related. On the other hand I’m not a fan of tools like Mosby or Moxy because I painfully found out they are rather constraining. Inheriting behaviour, state or plugins from base classes was catastrophic in our cases. Refactors and building custom behaviour for new screens were messy tasks and required much effort. Instead, use lifecycle aware components (again, see Android tools) or setup your architecture the way that you can call your business logic anytime. Some people calls it overhead. I would call it simplicity especially most of us happen to use caching.

4. Use dependency inversion frameworks extensively

Nowadays, there is world beyond Dagger. Dagger itself offers quite good support for Android apps also. You can leverage dependency inversion principle alongside with framework of your choosing to inject views the same way you are injecting other collaborators like controllers, use cases or data sources. That way you’re decoupling actual view from the place it is rendered.

The great news is your custom view is View implementation which means your Fragment or Activity doesn’t have to know what is rendered inside. Providing View subclasses enables you to use many custom views interchangeable as particular a component. Voila! Basic A/B testing setup done. Based on condition X you’re providing View Y or Z. Or you want to support multiple apps with one codebase. No worries, just inject different views for different flavours. There is much flexibility in this approach.

The only thing that Fragment or Activity need to do is to add view
to the layout (programmatically or through inflated xml if you want to
be direct). Don’t over-engineer it since you cannot escape from those
few lines. Just show/hide/gone view first based on the state that must
be rendered on the screen, and then optimise if necessary.
We’re building an app for Android OS 6+ so obviously those devices are quite fast devices. We have not encountered any glitches.

Oh, and really focus on cleaning up dependencies declarations like Dagger Modules. If you don’t understand it — spend time on it. Leave readable
and understandable legacy to you colleagues. Piling up dependencies are the worst enemy of a clean dependency graph, could lower performance and definitely causes headaches while coding the solution.

5. Infamous parent-child dependency

Don’t introduce parent-child dependency in case of custom views. They really need to be testable and independent. You don’t want to create/mock parent view or controller in order to test a child. And you would need to create or mock such instances for UI or unit test eventually. Don’t introduce hidden dependencies like setup of a custom view partially delegated to the Activity/Fragment or parent view. And definitely don’t inject your Activity/Fragment to a custom view which could lead to cycle dependency and memory leaks. That would also mean other developers will not understand how to use your component. It’s not in reusable fashion.

The same goes for view controllers (Presenters, ViewModels, Models, etc). Don’t introduce parent-child link between them. Navigation and analytics are the common mistake — just inject those (hopefully) reusable components to custom view controller instead of calling methods from parent controller in order to do any job like analytics tracking.

In summary, what was the effect of aligning to those principles…

Simply put, reusable components which could be used anywhere in the app with only small changes to the codebase required. By architecting those properly you should be able to decouple from Android lifecycle hell.
TBH we still sometimes need to sync data onResume() or onPause() somehow. That is why we created an abstract class CustomView with onForeground()
and onBackground() methods which are then implemented by custom views. We have done it for simplify, since it’s not breaking good architecture rules. We’re still doing our research on this topic. We know some tricks including lifecycle aware components but in the end our goal was to decouple from lifecycle! I will update this article when and if solved.

So, for example, by creating a list of results which was decoupled completely from other components we were able to switch views inside the screen in couple of lines enabling A/B testing and easy multiple flavour handling. It is also in the testing stage, so stay tuned. I’m definitely eager to edit this or write new article after long-term usage of the solution.

The way to achieve that wasn’t easy. We talked to the client and other devs
a lot in order to simplify and learn what is really needed.
We started refactor in one place and then thrown away code. And started again because system and requirements were quite complex. But that enabled us to understand business requirements and technical dependencies which opened new perspective on the solution. We knew how to simplify.

Prerequisites

I assumed your codebase is prepared for custom views in a way that many other collaborators are already reusable, testable, independent components. Or at least you’re able to inject them where needed. That would mean Analytics, Navigators, business logic, sensor handlers components and much more. That really depends on your application and you need to resolve it for yourself. Hopefully, by using the above mentioned principles as a reference. Although, there are few basic rules:

Your business logic is separated from views and view controllers.
Your business logic can be easily injected and reused.
View controllers are decoupled from views and how views are rendered.
View controllers are framework agnostic.
View controllers are easily injectable to views.
Views are are easily injectable to Fragments/Activities.

DISCLAIMER

That is my story behind architecting reusable components for an Android app. I’m not saying it is silver bullet nor the best practise. Still, I consider above rules as a great approach to organise our system.
It was the first iteration we did in Tigerspike as a part of the larger project so stay tuned for more! Big shout out to my colleagues as they made this article possible. :)

I would love to see your comments, ideas and improvements as I’m looking to improve and share knowledge as much as possible.
If you want to reach me out I’m based in Wrocław, Poland.
From time to time I’m visiting London.
Here is my LinkedIn and Twitter.

App Links: Associating Multiple Android App Build Types with a Single Domain

Maciej — Sat, 27 Aug 2022 18:58:00 +0000

Although I won’t go into the configuration nor benefits of Android App Links,
you can find them here, here, and here, I would like to elaborate on the missing documentation bit.

Specifically, how to associate and verify ownership between your domain
(a website) and multiple build types of the same Android application
using a Digital Asset Links JSON file.
Simply put, how to get rid of disambiguous dialog in such an environment.

We do not want that, ever! Source: https://www.flickr.com/photos/adewale_oshineye/21830113332 Licence CC.

While it’s not groundbreaking research, this guide can spare you
a couple of hours or even days of waiting impatiently to see if ownership
over an app has been verified.

In most cases, you’re not able to deploy a Digital Asset Links JSON file
on your own, thus you’re dependent on a third party to do so.
It means waiting. It’s better to do it once, properly.

App links (deep links) are usually not a standalone functionality of an app
yet rather a collaboration between many teams that drives users
into an app (for example, marketing campaigns).

More precisely app links usually require a bit of collaboration from a mobile team and marketing/DevOps/web/backend/you-name-it team from your company.

Let’s give an answer by starting with a question.

Given the fact that an app has multiple build types, each having its own, distinct certificate fingerprint SHA-1
When a subset of build types points into the same domain
Then could ownership be verified for all build types using a single domain?

This is the “complexity” we’re facing. Source: DIY.

Let’s give an example since it might be confusing.

An app has DEV (debug) and QA/UAT/SIT (debug and release) build type configurations that are both pointing to the same domain (website),
say, uat.example.com. That means you have two “apps” with
two distinct signing key configs: two distinct SHA-1 certificate fingerprints are being used to validate ownership of App Links via a single domain that hosts the assetlinks.json file.

If you have a single domain, can you verify ownership of two apps using two distinct certificates?

Yes, you can, it’s documented.

Our case is a bit different. What if an app also has links configured for uat.mobile.example.com subdomain and both debug and release build types of the same app are pointed into it? Could I verify ownership upon a second subdomain using both debug and release certificates again?

The answer is: Yes, it can be easily achieved.

This is an assetlinks.json content you have to upload to your subdomains.

In the example above, the Digital Asset Links JSON file is configured to support a particular build type

“package_name”: “com.example.app.buildType1”

which should be verified using debug SHA-1 certificate

“sha256_cert_fingerprints”: [“debugCertificateFingerprintHere”]

while the second build type has a “release” nature and uses a release SHA-1 certificate for ownership to be verified

“package_name”: “com.example.app.buildType2”,
“sha256_cert_fingerprints”: [“releaseCertificateFingerprintHere”]

Lemme explain a bit. The Digital Asset Links JSON file is a plain JSON file.

It contains a list (table) of elements as a top-level element.

All you have to do is to provide an entry for each of your build types with an appropriate SHA-1 fingerprint. And deploy it in each domain you’re interested in. Voila!

This configuration is extremely useful if you love the flexibility and the opportunity of using any number of environments with any of your build types. It enhances the testability of an app and increases data diversity while easing debugging— all because you can choose which environment will be used while implementing and testing your application.

Yeah,sharing is caring, remember that!

Thank you, Wojtek for the peer review. It’s delightful to have such support. :)

If you wanna reach me do not hesitate to do so. :)

Linkedin | Twitter | email

Be effective with Bitrise CI for Android — the lessons I learned the hard way.

Maciej — Fri, 26 Aug 2022 09:52:43 +0000

Be effective with Bitrise CI for Android — lessons I learned the hard way.

I won’t elaborate here on how important and crucial for any software development-oriented team the continuous integration (CI) practise is.
I’m pretty sure we can all agree on how CI tools support our day to day effectiveness. How they **might **save dozens of hours spent on non-essential tasks. Yet, it’s common to present CI tools as a hassle; slow, bulky,
and unreliable pipelines bloated with chaotic events instead of fast, maintainable feedback loop configured to support both product quality
and team flexibility.

As the title implies, our CI process was far from optimal. We learned what “slow and chaotic” means the hard way. Below, you will find an overview
of each issue that slowed us down, with full explanation of what the solution was (including code and external links), as well as honest results measured by minutes.

In this article, you will find discussion surrounding architecture, flavour agnostic unit testing, Gradle usage as well as keeping your logs and artefacts deployment in order. Additionally, at the end of the article, several tips
and tricks beyond optimisation will be included.
It’s not a step-by-step tutorial. We gathered results that work for us,
and you have to **think them through. **If those solutions make sense to you then, and only then, apply them to your environment.

The landscape

In order to fully understand why we provided a particular optimisation
it is crucial to understand how our landscape looked at the time.

There is git flow approach in place, which usually means multiple feature *branches exist at the same time in a remote repository. There is at least one *pull request per story. Each pull request needs to go through an integration* process* meaning the newest commit in a pull request triggers a fresh CI build. That’s being done in order to ensure the newest change won’t introduce any flaws. Yep, automation and unit test suites test each software incrementation. Software Engineers in Test (SET) writes automation tests
as “a part of“ the feature in some cases.

We are supporting multiple modules as a part of our architecture.
Let’s assume it is a clean-ish architecture with domain, data and app layers packed into separate modules. Each of the modules has its own unit tests suite — between dozens to few hundreds of them per module. We have to support multiple flavours and they differ greatly. Each flavour has
a separate set of automation and unit test, although most of them are shared.

When it comes to infrastructure, there is a separate Bitrise workflow for every build type. Also, a separate one for each of: feature development,
automation efforts, release (tags) activities and after merging feature
to the develop. Seeing how many distinct configs we have, there is a need
to run multiple builds every day. We can’t and won’t have “infinite” amount
of concurrent jobs, so time devoted to each build is very important to us.
It’s also important because we value sh*t done the right way.

The basic measurement that will prove effectiveness here is build time — both entire build time or a particular step time (such as unit tests step or deploy step).

Improvements

Unit testing

The most commonly used feedback loop is unit tests suite, in particular
if you’re supporting multiple flavours for Android app and you want to be sure that none of the changes would break any of the flavours.
Unit tests are supposed to be a fast and reliable feedback loop, which can be automated at the CI level. So, we used docs and tutorials to set them up for
all of the flavours. After few changes to CI, we ended up with 30 minutes long unit test step for 3 flavours.
Yes, you read it properly: 30 minutes for 3 flavours.

Ok, let’s fix that.

After a little bit of research it occurred to us that we used two separate steps for unit tests. Android unit test step for Bitrise was running app module unit tests. Gradle Unit Test step was just running .gradlew test task.

Total time for each step in minutes.

What’s wrong with gradle unit test step in our case? According to the Gradle documentation:

Source: https://docs.gradle.org/current/userguide/command_line_interface.html

In simple terms, ./gradlew test* triggers *dozens **of different *test *tasks from every module. In our case, it triggered both debug and release related tests
for every subproject (*module)*. That’s too much redundancy; consider the final result of *./gradlew test *command:

(amount of flavours) x (amount of supported envs) x (amount of modules)

But the amount of tasks triggered is not all we can improve here.
I already mentioned we have several modules. Since it’s cleanish architecture, *it consists of *app, domain, data and api modules.
It’s easy to see that some of those modules are flavour agnostic — *domain, data and api layers can and should be treated as libraries. Those are *external dependencies that could be used via any JVM compatible code.
Do we need to run those tests separately for each flavour?
Of course we don’t! Where does it lead us?

Flavour agnostic unit tests

Split flavour dependen*t and *flavour agnostic unit tests. Gain greater control over how your application is tested. Use Gradle Unit Test step in your Bitrise.yml to run targeted flavour agnostic unit tests, like this:

Using unit_test_task *attribute enables you to configure a particular task to be run. Basically, any gradle task. You can obviously chain gradle commands, but I want **granularity* here. Additionally, the usage of *title *attribute keeps build logs in order and enables you to track each step separately.

The result of applying the above mentioned recommendations. Cleaning up resources gave us unit tests result in seconds instead of minutes.

Flavour dependent unit tests

The second recommendation relates to Android unit test step for Bitrise
and how flavour dependent unit tests are managed. In most cases,
I would recommend you to run only what you need. But I came to conclusion that ‘run only what you need’ could be counterintuitive in our case.

It’s really easy to break one of the flavours by introducing changes to only one of them. That’s why we ended up with running unit tests for every flavour in every build. In addition, the above mentioned set of *flavour agnostic *tests is triggered. What does it mean when it comes to Bitrise CI setup?

The above snippet runs unit tests for the app *module for a particular flavour injected as an *environment variable and a particular build variant.
So, if CI builds only one flavour at time, this snippet is supposed to be triggered three times, once for each flavour. If all of the flavours are built simultaneously, then each flavour should run its own unit tests in order to avoid redundancy and save a few minutes from build. Notice that, before _UnitTestsPerFlavour step, UnitTests_Flavour_Agnostic_Modules *step is triggered. It runs flavour agnostic tests, so *domain, *data and feature *modules unit tests. Either way, all unit tests are always validated.

Alternatively to the above setup, you can use the following setup to hardcode which flavour’s unit tests should be run:

That way we’re all covered, no matter if we’re building all the flavours, or just one. Remember, the lesson here is flavour dependent and agnostic unit tests should be triggered once. There is no redundancy, but there is full coverage. Every software increment is safe.

Results

We started with around 30 minutes per build.

Total time for unit testing then.

And finished up with the below results when running one flavour.
Down to ~5/6 minutes per build.

Total time for unit testing now.

And also **down to ~3 minutes per build **when running all the flavours
at once, which means each flavour is responsible for its own unit tests finally. Yes, that’s a separate config in order to optimise build time even further.

Total time when running all of the flavours. Build time for those unit tests per one flavour.

Artefacts Deployment

Review your D*eploy to Bitrise.io *step. According to the documentation [1] [2] [3] for the following steps test reports are deployed automatically:

Xcode Test for iOS
Android Unit Test
iOS Device Testing
Virtual Device Testing for Android

As noted in the documentation, by default Android unit and UI tests are deployed to Bitrise directory and are provided via the Test reports tab. They are easily accessible — but the question is — are they really necessary?

We have robust unit tests. They fail rarely in CI because the entire team writes and runs them frequently. On the other hand, it’s easy to check Bitrise for which logs failed.

Deciding what to deploy

We already changed from Android unit test step for Bitrise to Gradle Unit Test step which does not deploy unit tests reports automatically. And we want it that way. What about the rest of the artefacts? For *automation *builds we’ve decided not to deploy any APKs. They are not needed.

We also already know that Virtual Device Testing for Android step deploys UI tests results into the Test Reports directory. We decided that for all of the builds we are going to move or remove D*eploy to Bitrise.io step completely as an experiment.
Also, D*eploy to Bitrise.io *step is always triggered before unit tests but after APK creation. That way, only application (*uatRelease APK for example) and the UI tests report are deployed.

Initially deploy to Bitrise.io *step took from 2.1 to 3.2 minutes*.

Initially 3.2 min was total time per this step.

After the changes it’s 0 minutes for some builds. It is ~8 seconds for most of them.

That’s how quick it could be!

Oh yeah! Source: https://knowyourmeme.com/photos/988454-we-did-it-reddit

Automation workflow

One of the low hanging fruits was to change what is being done
as a part of a particular workflow, since they all have different goals.
As I mentioned, we have feature, automation, develop and release workflow.
In our case, initially, all of the mentioned workflows had basically
the same setup. Why is this wrong? Because, as we said, workflows simply have different responsibilities.

Understanding the differences in workflows

I have already mentioned the automation workflow. It’s because it is special compared to other workflows. The only responsibility automation workflow has is to support Software Engineers in Test in writing and securing automation test suite. That simple conclusion means we can trim
several steps from it; in our case, APK and other artefacts creation
and deployment. We were also able to get rid of custom scripts we had there for the release app or “runtime” resources optimisations steps and beyond.

Results

By doing this, the *automation *build is a fast feedback loop for the SETs.
**It takes around 10 minutes less than other builds.
**I believe it’s a huge win for the SETs team.

Investigating tools configuration

Here is a quick and simple story as an example. Our builds produced uatDebug and uatRelease APKs. UAT stands for ‘user acceptance testing’ and it’s also a name of one of our environment s— environment with almost production setup but more over development data — and simply used for testing purposes. So, producing those two build sounds about right, doesn’t it? I started asking questions anyway. We were sure we need uatRelease for testing purposes. It makes sense since testing production ready app (release) using development data (uat) is one of the best practices. But why do we need *uatDebug *then?

Trimming unused resources

The sole reason was a misconfiguration of the Charles proxy tool, which led testers to not being able to use proxy tools while testing uatRelease *build variant. Famous *network_security_config *file had been added to the project but it wasn’t working, since the build variant has to be *debuggable. *The quick fix was to add *android:debuggable attribute to all uat *builds. And since we’re not testing *uat builds using any public channels — it’s secure enough.

Results

A simple configuration fix to the existing toolset brought an 8 minutes time reduction to each build and fixed SETs headache.

All numbers together

In summary

Unit tests time **down from 30 minutes to 3~6 minutes. **Depends on build type.
Automation build cut off by another 10 minutes through removing a few unnecessary steps.
Artefacts deployment reduced from 2.1~3.2 minutes into 8 seconds!
Fix to Charles configs gave us another 8 minutes — due uatDebug build removal.

We were able to shorten builds by between 48 minutes and 34 minutes
per each build. That was a huge win and relief as you can imagine!

We obviously made some rookie mistakes. But the most important part
is to learn from them. We were able to adapt quickly and we’re providing other small improvements since then. It can’t happen on a daily basis because we also need to deliver business value to our clients — but with an appropriate plan in place, I’m sure you can do even more.

Tips and tricks beyond optimisations

Bitrise and its plugins’ documentation is quite limited. You will need to deep dive into the plugins code if you want to understand the platform fully. Plugins code is mostly open source — you can find links inside plugin documentation. In particular, review the *main.go* file if you’re looking for attributes and parameters which could customise the build.

Use Bitrise CLI in your terminal in order to test configuration locally. It will save you a lot of time.

Have as granular CI steps as possible. Use *title *attribute extensively. Greater readability — greater control over time. Solid foundations are the first step for future optimisation.

Do what we haven’t done yet — introduce tools to measure build metrics automatically.

Leverage version control since Bitrise is similar to infrastructure as a code.

That’s a separate story but in Tigerspike, we optimised APK size by 13% during our internal hackathon day. You should be aware of best practises for Android app configuration. Get rid or optimise resources, configuration and APK size. These kinds of things are also impacting your build time: git pull, compilation and build time, tests, deploy time — these are some of many examples.

Listen. Observe. Experiment. Formulate a plan and adopt only what’s needed for your team. Good luck!

Thanks! Source: http://123emoji.com/donald-duck-stickers-2-9606/

I hope you like this piece. As you can see I love a fast feedback loop —
if you have any objections, comments or questions — please drop a comment or DM message.

The article showcases what we have done for one of our projects in Tigerspike. We’re hiring — please mention my name! ;)

If you want to reach me out, I’m based in Wrocław, Poland.
I’m also visiting London from time to time.
Here is my LinkedIn and Twitter.