For all my university software projects, I use the HdM Gitlab instance for version control. But Gitlab offers much more such as easy and good ways to operate a pipeline. In this article, I will show how we can use the CI/CD functionality in a university project to perform automated testing and an automated build process.
Continue readingWritten by: Immanuel Haag, Christian Müller, Marc Rüttler
The goal of this blog entry is to automate the previously performed steps. At the end all manual steps should be automated when new code changes are added to the repository. The new version of the backend will be made available in the cloud at the end.
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.
Continue reading
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.
Continue reading
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:
Continue reading
You will learn the steps necessary to configure the CI pipeline and best practices in relation to a CI pipeline for Unity projects.
Continue reading
You must be logged in to post a comment.