The containerization of our services has helped us a lot to reach high scalability in tailoring and mass customization. Containers offer superior manageability, security and customizability for most innovative users and agile teams with DevOps mindset.
In this blog post, we are covering the basics and main benefits of Bitbar’s container technology. With the next ones we’ll cover what the containers contain for Android and iOS respectively, then we will deep dive on some advanced use cases utilizing the containers beyond mobile test automation and then, finally, we will be showcasing an end-to-end use case including also containerized backend.
Containers as Part of Mobile DevOps
When you are using real devices from Bitbar Cloud you may not realize that in addition to the real mobile devices you also get access to a dedicated (and virtualized) Mac OS X or Linux server. The image below illustrates how this works on a high level:
Step 1: Mac OS X or Linux server is waiting for a job from Bitbar’s cloud logic.
Step 2: Mac OS X or Linux server receives a job, spins up a Container/VM instance, connects the instance to the device over USB and starts the session.
Step 3: When the session is done the Container/VM instance is killed, the device cleaned and the system is ready for the next session.
Benefits of Containerization for Mobile DevOps
Using containers as part of your mobile DevOps has several benefits:
As the sessions are executed every time in a fresh firewalled container that is then discarded after each session it is very unlikely that there is any leakage of data or any other security risks from one session to another.
Firewalled containers form a secure sandbox for each test session and any changes made during the session impact only the sandbox for the duration of that session.
The container-based architecture helps the administrators of Bitbar Cloud (whether it’s a public cloud, private cloud or on-premise setup) to manage the system more efficiently. When using containers the administrators can rely that each device server has the same configuration and when there are changes to the configuration it is easy to make the change to just one script that creates the container images and the automation will do the rest from creating the container image, validating it and then deploying the new container image to all servers.
Due to the container based architecture adding new devices and servers is very fast and repeatable as the container automation bootstraps new device servers in parallel at large scale removing the chances for human errors of manual deployment.
Because of the container based architecture, you get shell-level access to the virtualized Linux/Mac server where you are executing your tests. For advanced users, this is a great benefit as they can utilize these servers for a variety of tasks such as building their app binaries, running code analysis, deploy their apps to app stores, etc.
If there are some libraries or tools missing from the standard container you can easily install those during the session by using
run-tests.sh file to control your environment. Again, because everything is happening inside of firewalled sandbox all customizations pertain only to the current session and do not have any impact on other users or devices.
Using containers makes Bitbar Cloud also very scalable from a user’s point of view. Because there are no artificial limitations on the number of concurrent sessions, you can spin up as many identical environments as you need.
This parallelism will significantly accelerate your workloads, whether you use the environments for running tests, compiling application binaries or for scanning through your code for in static code analysis purposes. Scale means saved time and that means more time for you to focus on value-adding tasks.
In the next blog post of this series, we will introduce what tools and libraries are included in standard Bitbar Mac OS X / iOS containers and we’ll show some examples how you can customize those to suit your needs.