When you are working in a bigger company or agency which develops and ships a lot of apps, the release process can be very time-consuming. In such a scenario, a lot of people are involved like the IT department, the app owner, testers and of course the developers themselves. Additionally, all these people use different tools for development, testing and distribution which leads to a fragmentation of the IT infrastructure and spread credentials across all of these tools. Another important thing to keep in mind is the responsibility for these tools and the infrastructure which is rarely clear. As a developer, for example, I do not want to be responsible for the management of the source code repositories and continuous integration infrastructure. As a responsible IT infrastructure manager, I do not want to deal with problems in the code of the business app and how the app is built by the CI tool. While the demand for fast delivery is growing, why isn't there an infrastructure which can solve these problems once and for all? Let's anticipate - there is a solution!
The combination of the leading Git repository and continuous integration tool out there - GitLab and Relution, the only full app lifecycle management tool solves these problems.
The whole app release process, from setting up new app projects and the needed infrastructure to shipping apps to your enterprise or public app stores, can be simplified and automated.
There is no need to prove that the use of code repositories and continuous CI/CD tools (Wikipedia) help development teams in software projects. GitLab is one of the three big players out there (together with GitHub & BitBucket) and finds a lot of use, especially in enterprises and agencies (according to the GitLab website, it is used by more than 100,000 organizations). It has a rich feature set which covers the whole development lifecycle and a huge community alongside a lot of possibilities for extensions and scripting possibilities. One of the great things about GitLab is the combination of Git repositories and continuous delivery build jobs. Developers can check in their code, define a so-called .yml file which has all the commands to compile, build and release an app and the integrated continuous delivery mechanism builds the app automatically on every new commit.
Relution is a mobile app lifecycle management tool which has a specific angle on app projects in general. It supports the release lifecycle of different app versions and provides an infrastructure for app management. After an app has been uploaded to Relution (of course, this step can be automated), it allows app owners to release the app in different stages. You can define permissions for developers, testers and app owners, so the app can be reviewed in different stages. Additionally, Relution can manage metadata of apps like descriptions and screenshots and also automatically re-sign apps. This, especially, helps enterprises with a lot of external app agencies to not spread their signing credentials to people outside the company and ensures that every app is re-signed correctly with the chosen enterprise certificates. Relution also lets companies benefit from an own app store which is used for company apps. This feature is mainly used for company apps which should not be distributed through the public app stores - like internal apps, CRM apps or other business workflows.
Coming back to the problem described in the introduction, we want to show you a solution which consists of a setup of both tools. Here is how a workflow could look like in reality:
How do you like this workflow? You certainly have questions, right?
Relution uses a lot of GitLab's great features in the background. If a 'development environment' is approved by the IT department, a new project repository is created. It is pre-filled with two important files: the .yml file and an upload script. The .yml file is used to set up a build job and the upload script is used for uploading the build app artifacts into Relution for further processing. Additionally, the developer permissions are set automatically on the GitLab server on the repository, so the defined developers can use their SSH key to work with the repository. GitLab can (but doesn't have to) stay in the background since the developers can define their build parameters in the .yml file. The built apps can be distributed to the developers through the Relution app (so, in fact, the developer commits something, and after a while, he receives the built app on his mobile device for testing). Of course, the developers need to upload their public SSH key to Relution before cloning the repository. By default, a new build on the Continuous Integration server is triggered when a developer pushes changes to the master branch. The build artifacts (apps) created by a successful build will be uploaded to Relution and are linked to the corresponding Development Environment. Uploaded apps are visible in the App Store view or via the Development Hub by selecting the appropriate Development Environment in the Relution Portal.