(Originally written for System Engineering and Management in 02/2020)
In the System Engineering course of WS1920, I took the opportunity to look into automating the build process of a Windows desktop application. Specifically, the application in question is built in C#, targeting .NET Framework 4.0 and using Windows Presentation Foundation (WPF) for the user interface. The git repository is hosted on GitLab.com, making this environment the primary focus of this research.
The main objective of this project was to set up a low cost and maintenance build pipeline for a Windows desktop app, but also to gain a better understanding of GitLab’s CI/CD system as well as Microsoft’s .NET world, both of which I had dealt with before, but never in great depth. Ideally, the end result would come without any financial cost, so that any private person, without a budget to spend on a build server or other payed services, would be able to use it.
This is part two of our series on how we designed and implemented a scalable, highly-available and fault-tolerant microservice-based Image Editor. This part depicts how we went from a basic Docker Compose setup to running our application on our own »bare-metal« Kubernetes cluster.
This is part one of our series on how we designed and implemented a scalable, highly-available and fault-tolerant microservice-based Image Editor. The series covers the various design choices we made and the difficulties we faced during design and development of our web application. It shows how we set up the scaling infrastructure with Kubernetes and what we learned about designing a distributed system and developing a production-grade Kubernetes cluster running on multiple nodes.
In this article we will explore IPFS, the InterPlanetary File System. IPFS is a system for storing and accessing files, websites and other kinds of data — just as the Web we enjoy using every day — but unlike the Web, IPFS is peer-to-peer based and automatically distributes its content across the network.
- Tim Landenberger (tl061)
- Johannes Mauthe (jm130)
- Maximilian Narr (mn066)
This blog post aims to provide an overview about how to setup a decent CI/CD workflow for an android app with the capabilities of Gitlab. The blog post has been written for Gitlab Ultimate. Nevertheless, most features are also available in the free edition.
The goal is mainly to provide an overview about Gitlab’s CI/CD capabilities. It is not object of the blog post to test and/or develop a complex android app, or to handle special edge-cases in android app development.
The blog post covers the following topics:
- Defining a decent pipeline
- Automatically running unit tests
- Automatically running integration tests
- Automatically running static code analysis checks
- Automatically running debug/release builds
- Automatically distribute the app for testers
- Adding Gitlab’s drop-in features
- Dependency management
- License management
When a distributed software system grows bigger and bigger, one will end up with a big amount of various components which all need to scale independently. In order to achieve these components working smooth together, it is necessary to figure out at which time a component needs to be scaled, to avoid having one component as a bottleneck.
This blog post focuses on the possibility to test the behaviour of a large scale system under extreme load in order to discover vulnerabilities. Therefore I will provide an overview of scalability testing and a more specific variant, which has already proven itself as a successful testing variant for such systems, called Chaos Engineering.