In the first part we pointed out how we set up the infrastructure for our CI system. Now we would like to explain how we build a pipeline for our cross-platform application and what features of GitLab CI we made use of.
Hosting your own GitLab server
Some users might have concerns regarding security using GitLab for a variety of purposes, including commercial and business applications. That is, because GitLab is commonly used as a cloud-based service – on someone else’s computer, so to speak. So setting it up for running it on your own server is the conclusion, whether it be a NAS, real dedicated server or even a Raspberry Pi. So, as a side quest, we decided to set things up on a Raspberry Pi Model 3 for comparison. The following part will cover the installation procedure (mostly according to the official GitLab page) as well as hints to some potential pitfalls.
Our first approach was to use the existing GitLab instance of HdM for our project. For them, a shared runner was already defined on which we could run our jobs, so we were able to focus on the CI process itself. This plan worked out at first. We simply defined build and test jobs, which passed without any problems. But when we tried to deploy to our staging server we were a bit confused, because no matter what we tried, the SSH connection to the server could not be established. Even after several reconfigurations of the keys and rewriting of the job we did not succeed, which was surprising, because we could connect to the server from our PC via SSH without problems. Finally, we found out that the HdM firewall blocked our SSH connection to the outside. Since the “HdM-GitLab solution” seemed to be a dead end, we decided to set up our own GitLab instance to be independent of external configurations.
When it comes to software development, chances are high that you’re not doing this on your own. The main reason for this is often that implementing components like UI, frontend, backend, servers and more is just too much to handle for a single person leading to a slow development process. So, you have to team up with others. Therefore some collaboration tools (e.g. SVN, Git) have been established so that you don’t accidentally overwrite someone else’s code and vice versa.
The big challenge with such collaborative projects is to ensure a high quality of the software even with a high level of developer activity. One instrument for this is continuous integration, whereby the individual application components are continuously brought together and successful interaction is ensured.
Especially in large projects high software quality and a structured development process are of enormous importance. That is why we decided to carry out the complete development and quality assurance process from the creation of a project, the definition of tests and continuous integration of the components to the automatic deployment of the application using a small sample project.
The following image shows the architecture of the small node application:
You will learn the steps necessary to configure the CI pipeline and best practices in relation to a CI pipeline for Unity projects.
Continuous Integration is an increasingly popular topic in modern software development. Across many industries the companies acknowledging the importance of IT and delivering value to their customers through great software prevail against their competitors. Many reports indicate that Continuous Integration is one of the major contributing factors to developing high quality software with remarkable efficiency. There are many excellent articles, talks and books explaining the principles of CI in theory. During the lecture System Engineering and Management, we had the opportunity to apply our abstract knowledge and gain our own experience by creating and operating a CI pipeline in an accompanying project. The following article covers the approach, major challenges and most important the lessons learned of our Continuous Integration endeavor. By pointing out relevant issues we want to raise awareness on our misconceptions and mistakes we committed so you can avoid them in the first place.
When we started the project “Flora CI” for the lecture “System Engineering”, we planned to deal with Continuous Integration. As an important aspect of software engineering all of us have previously been involved in projects where code of developers had to be merged and builds had to be automated somehow. Anyway we felt we could dive deeper into CI pipelines and learn what it needs to get them running in a performant, useful and reliable way.
On our journey building such a system we also planned the containerization of all components in order to achieve the strongest possible encapsulation of the individual processes and to gain experience in this topic as well. Another planned goal was the automatic deployment into the corresponding Android and iOS App Stores as well as the provision on a web server.
Related articles: ►CI/CD infrastructure: Choosing and setting up a server with Jenkins as Docker image ►Dockerizing Android SDK and Emulator for testing ►Automated Unit- and GUI-Testing for Android in Jenkins ►Testing a MongoDB with NodeJS, Mocha and Mongoose
During the winter term 2017/2018, we created an app called Take Me Home. The purpose of the app is to guide you home in case you are not able to find the way back home by yourself. There are several situations in (a student’s) life when this functionality can be very useful. For example, under the influence of a specific amount of alcohol even an easy and short path back home can get rather challenging. In this case one can use Take Me Home to find a fast and save way back home.
Related articles: ►Take Me Home – Project Overview ►CI/CD infrastructure: Choosing and setting up a server with Jenkins as Docker image ►Automated Unit- and GUI-Testing for Android in Jenkins ►Testing a MongoDB with NodeJS, Mocha and Mongoose
During our Android development project, we had to cope with several technological and organizational challenges with regard to construct a stable CI pipeline. Due to our chosen stack of Docker containers for building and deploying we had to confront with the topic how to integrate and deploy a building and testing environment for Android in Docker.
For a better understanding of this challenge following illustration of our stack can be consulted:
Related articles: ►Take Me Home – Project Overview ►CI/CD infrastructure: Choosing and setting up a server with Jenkins as Docker image ►Android SDK and emulator in Docker for testing ►Testing a MongoDB with NodeJS, Mocha and Mongoose
In this article we would like to describe, how to write unit- and gui-tests for an Android-Application in Android Studio and how-to automat these tests on Jenkins.
Tools and frameworks
We used the following tools and frameworks to write and automate our tests:
- Android Studio
To test the basic functionality of your app, the best way is to run a unit-test. Continue reading