Container technology and products aren’t new anyhow in mobile development today. The LXCs – Linux containers – which combine certain important kernel components to isolate resources have been around for a decade or so. But to get container technology for everyone the use of popular containerization products such as Docker have helped many mobile developers to build clean and separated environments where things just work like “on my machine”.
In this blog, we’ll take a look at some technical aspects of containers and how to use those as part of your mobile app testing process.
Containers vs. Virtual Machines
Among these container products, developers got an instant environment where things would work identical work regardless of environment, tools, programming languages and other dependencies. It would be just those components included in containers that matter for execution of a software piece. Comparing containers to virtual machines there are few differences that make containers a better fit for mobile development environments. One of those is the quick ramp up and customization of what goes inside the container.
There is absolutely nothing wrong with virtual machines but the key characteristics with those favoring the use of containers – and we’ve great experiences of using containers as part of our cloud environments (public and private, plus our on-premise setup). And many enterprises with mobile apps are looking to adopt a true Mobile DevOps culture inside their organizations. This type of company culture shift has changed the way how organizations operate their development, operations and testing teams – and again, containers are an essential technology to use when enabling mobile DevOps for any organization.
Mobile development is nowadays all about continuous integration, deployment and instant test automation on a variety of real mobile devices. With all of these setups, containers can quickly scale and provide an environment where test automation can happen different tool options, programming languages, middleware components and dependencies that mobile application would require to run later one (e.g. back-ends). Even those back-ends could be included in those containers and that makes use of containers superior, clean, fast and highly scalable.
Containers Work for Different Mobile App Testing Deployment Options
Containers – and generally container technology – can be used in various cloud deployment options, such as public, private, and hybrid clouds. Containers provide a great alternative way to virtualize (vs. what virtual machines with server setups provide) and those are quick to configure and scale up. Even experimental containers may be a good idea for mobile app testing. Including pretty much anything in those containers allow mobile app developers, testers, QA people and other IT professionals to build an identical environment for mobile app testing and test automation.
Private Cloud. One of the best examples is our private cloud deployment option. Customers get to decide what goes in those containers and what software components are critical for test automation. The goal of this type of customization is to help and enable mobile DevOps use regardless of where the infrastructure and mobile devices are located.
On-Premise Environment. Naturally, containers are great also for on-premise mobile app testing setup. Using containers in localhost with devices connected to local servers and powerful test automation solution that can provide and enable unprecedented parallelism and concurrent use of mobile devices. On-Premise test automation for mobile apps also provides enterprise-grade features for security, load balancing and LDAP for accessing and maintaining distributed information over an IP network. This basically doesn’t have any implications on containers if a network connection is available.
How to Tackle Challenges with Containers in Mobile Testing
In general, containers in the cloud do not have the same security boundaries as virtual machines but those can be easily misconfigured and things won’t run as expected. Containers per se aren’t that vulnerable to security threats and hackers can’t exploit those that easily as with a certain type of static infrastructure.
Containers are executed only for a certain period of time, which actually makes them more secure and time is of the essence for malware, security threats or hackers to exploit the system. Overall, all environments where containers are executed always expose security threats and certain environments (on-premise and private) are the most secure with a variety of different security mechanisms built in those.
Another thing where we’ve seen people getting confused is the creation of containers – and how the process goes after things run on the local environment. However, this is something that can be quickly and easily verified as containers can be tested on various environments (localhost and cloud deployments) and further configured for better usability.
People also stumble with managing multiple versions of container images. Especially when components change or a software component version change, it may be more difficult to update and maintain multiple same software components and their versions with container images. However, we’ve used certain containers with 10+ different versions of a test automation framework in one container and everything has worked well. It’s just what run.sh script or other configurations in container want to get in use for test automation session.
Eventually, every organization must consider what type of mobile app testing solution fits the best for their needs, what security level should be built in, what set of mobile devices should be used and how to get solid infrastructure around this. From Bitbar, you can find the most scalable and the best fit for your mobile app testing environment, with the right container setup and the best reconfigurability and scalability.
Happy Testing Folks!