Seite wählen

NETWAYS Blog

A peek into GitLab 11, the Web IDE and Auto DevOps with Kubernetes

GitLab 11 was just released last week and introduces a bunch of new features. I’ve picked the most exciting ones for a short peek as our hosted production environment was already upgraded by Stefan 🙂
 

Web IDE

You can already add and edit files directly in your browser. Dirk mentioned this in his blog post, it motivates open source contributors to enhance the documentation. For larger changes we are used to fire up an IDE like Visual Studio, JetBrains Goland, PHPStorm, Atom, Eclipse, etc.
Sometimes you don’t need a full blown IDE, or you don’t have access to on your mobile device. It would be nice to have immediate results from build, compile and test stages, best in an isolated (container) environment.
The newly introduced GitLab Web IDE attempts to become a new player in the field. On the right you can already see the current pipeline job status from the latest commit. Once we’ve edited the file, we can commit (and push at once) and the CI will trigger a new job run. Just awesome!

In its current implementation, the IDE is accessible from files view only, but the roadmap proves that there’s more to come on project creation. Just type t in the main project view and search for a specific file. Then pick Web IDE from the upper left bullets and rock on. There is syntax highlighting and code auto-completion included ❤️


 
 

Auto DevOps with Kubernetes

Our vision is to replace disparate DevOps toolchains with a single integrated application that is pre-configured to work by default across the complete DevOps lifecycle.

Auto DevOps enables your CI/CD workflow to advance even further with pipeline container environments built on Kubernetes. GitLab provides its own Kubernetes integration, accompanied with default templates for projects and build pipelines. This isn’t limited to build, test, deploy stages but also includes a variety of additional stages:

  • Build and Test
  • Code Quality checks
  • Static Application Security Testing (SAST), Dynamic Application Security Testing (DAST), Dependency and container scanning for vulnerabilities
  • Review Apps, deploy current state to temporary application environment in Kubernetes (optional)
  • Deploy to Kubernetes production environment (optional)
  • Monitoring for fetching deployment metrics from the Kubernetes cluster via Prometheus exporter (optional)


 
You can see the changes inside the menu where Operations was introduced and provides settings for environments and Kubernetes integration. This was previously found in the CI/CD section. A Kubernetes cluster can be assigned to a specific project, you can safely play and test without harming a global environment.
Nicole and Gabriel shared more insights into GitLab 11 features in their OSDC talk on „Git things done with GitLab!“. Check the archive for a live demo especially on the Auto DevOps feature, first time I fully understood its purpose 🙂
 

Notable Changes

In terms of roles, GitLab renamed „Master“ to „Maintainer“.

GitLab also decided to release the „Squash and Merge“ option into the Open source edition. This feature allows you to develop a merge request in multiple commits, and upon merge back to master, it will automatically squash the commits into a single one. Want to learn more about git squash? We’ve got you covered in our GitLab training 🙂


I really hope that GitLab will also open-source Merge request approvals in future releases. This is something which we use for code review and release managed on GitHub on a daily basis and would enhance our GitLab flow too.
Still not enough? I’d love to talk GitLab with you in our upcoming training sessions, including the best development workflows from our daily work 🙂

Microsoft and GitHub – merge conflict?

For some time it has become clear that Microsoft is going to take over GitHub. As far as official sources can be trusted, GitHub will stay independent although a new CEO (Nat Friedman) will be introduced after the Microsoft takeover.

This question over GitHub’s future independence has raised a lot of skepticism within the developer community and many are considering moving their projects away from GitHub to a different location.
One alternative in this case could be GitLab. GitLab does not only have an online platform but it can as well be installed on your own hardware. Furthermore, it is an extremely solid piece of Open Source software you can fully rely on. This is also shown by the makers of GitLab themselves as they release updates each month – rolling out bug fixes, security updates and many recommendations regarding the use and configuration of your instance.
For those who would like to have their own GitLab instance, NETWAYS offers two options:
First one is available on our NETWAYS Web Services platform where we offer user-managed, hosted GitLab instances as Community or Enterprise Edition. The user does not need to take care of anything regarding installation or maintenance of his GitLab, but can directly go into production in no time with only a few steps needed. You as a customer are also free to decide for how long you would like to run your instances as any app is monthly callable. Furthermore, we regularly update these container based apps and monitor their health  for you. As a customer, you can register on NWS and try all the apps we offer 30 days for free.
The second product we offer is done by NETWAYS Managed Services which is exactly what it is called: With managed hosting you can get a virtual machine in our cloud or rented hardware running a full GitLab, either as Community or Enterprise Edition. You can choose the underlying ressources and we will do the rest for you, like installation with individual parameters and health monitoring. With managed hosting, our customers also have the choice to go full 24/7 support with „emergency“ calls.

Continuous Integration with Golang and GitLab

Today you not only develop code and collaborate with other developers in your Git branches and forks. In addition continuous integration helps with „instant“ compile and runtime tests. Which Git commit caused a failure, are there any performance changes with the recent code history?
Today I want to dive into our latest insights into Golang and building our code inside GitLab on each push and merge request. Golang extensively supports unit tests and also their analysis with coverage tests. This ensures that code isolated in test interfaces runs rock-solid and you can focus on the more important tasks and features.
In order to abstract the Go build and install calls, we add a Makefile for convenience. This also allows developers to manually use it, if they want.

$ vim Makefile
.PHONY: all test coverage
all: get build install
get:
        go get ./...
build:
        go build ./...
install:
        go install ./...
test:
        go test ./... -v -coverprofile .coverage.txt
        go tool cover -func .coverage.txt
coverage: test
        go tool cover -html=.coverage.txt

The „coverage“ target runs the tests and stores the coverage results in „.coverage.txt“. This is then converted into HTML and can be opened with a browser for example.
Inside GitLab we need a CI runner configured for our project and job pipeline. This is already available in the NWS app. If you want to learn more about GitLab CI/CD, containers, jobs and pipelines, I’ll invite you to join me for the official GitLab training sessions 🙂
The CI configuration file is stored in „.gitlab-ci.yml“ inside the Git repository and uses the Golang image for Debian Stretch in this example.

$ vim .gitlab-ci.yml
image: golang:1.10-stretch
stages:
  - build
before_script:
  - apt-get update && apt-get install -y make curl
  - curl https://raw.githubusercontent.com/golang/dep/master/install.sh | sh
  - mkdir -p /go/src/git.icinga.com/icingadb
  - ln -s /builds/icingadb/icingadb /go/src/git.icinga.com/icingadb/icingadb
  - cd /go/src/git.icinga.com/icingadb/icingadb
  - dep init && dep ensure
build:
  stage: build
  script:
    - make test

The „before_script“ tasks can be moved into your own Docker image which can be made available in the GitLab container registry too. At some later point when dependencies are fixed, we’ll remove the „dep init“ step and just use the locked versions from inside our Git repository.
The test coverage should also be highlighted in the job output. This can be extracted with a regular expression using the shell output from the tests. Nagivate into „Settings > CI/CD > General pipeline settings > Test coverage parsing“ and add the following regex:

^total:\t+\(statements\)\t+(\d+\.\d+)%

Each pushed branch and merge request will then automatically be built and also shows the test coverage. There’s room for improvement here, the next months will ensure to add more unit and runtime tests ?

Releasing our Git and GitLab training as Open Source

Development is super fast these days, there are many tools and integrations to make it more comfortable. One of the version control systems is Git, next to well-known SVN and CVS. Git got really pushed by GitHub and most recently GitLab which provide entire collaboration suites. Nowadays you not only commit code revisions/diffs, you can also test and deployment changes immediately to see whether your code is good on defined platforms or breaks. Issue and project management is put on top and makes it very easy to collaborate.
Continuous integration (CI) allows for deeper code quality too. Add code coverage reports, unit test results, end2end tests and actually build distribution packages with tests on many platforms included. In addition to CI, continuous deployment (CD) adds the icing on the cake. Once CI tests and package builds are fine, add a new build job to your pipeline for automated deployments. This could for example push updated RPM packages for your repository and immediately install the bugfix release in production on all your client hosts with Puppet or Ansible.
You can do all of this with the ease of GitHub or your own hosted GitLab instance (try it out in NWS right now!). Don’t forget about the basics for development and devops workflows:

  • Untracked files, staging area, … what’s within the .git directory?
  • What is a „good commit„?
  • I want to create patch for an open source project – what’s a „pull request„?
  • Workflow with branches?
  • A developer asked me to „rebase your branch against master“ and „squash the commits“ … what’s that?

Our Git training sessions have been renewed into a two day hands-on session on Git and GitLab. Many of us are using Git on a daily basis at NETWAYS, in addition to GitLab. Knowledge which we share and improve upon. The training starts with the Git basics, diving into good commits, branching, remote repositories and even more. Day 1 also provides your own NWS hosted GitLab instance.
Starting with day 2, you’ll learn about development workflows with branches and real-life use cases. Continuing with CI/CD and generating your own Job pipeline, and exploring GitLab even further. We’ll also discuss integrations into modern development tools (Visual Studio, JetBrains, etc.) and have time to share experiences from daily work. I’ve been working with Git since the beginning of Icinga more than nine years ago.
We have open-sourced our GitLab training material. We truly believe in Open Source and want make it easier for development and contributions on your favourite OSS project, like Icinga.
You are welcome to use our training material for your own studies, especially if you are an open source developer who’s been learning to use Git, GitLab and GitHub. For offline convenience, the handouts, exercises and solutions are provided as PDF too.
Many of the mentioned practical examples and experiences are only available in our two day training sessions at NETWAYS so please consider getting a ticket. There’s also time for your own experience and ideas – the previous training sessions have shown that you can always learn something new about Git. You can see that in the Git repository and the newer Git commits, where this feedback was added to the training material ❤️
See you soon at the famous NETWAYS Kesselhaus for a deep-dive into Git and GitLab!
Please note that the training material is licensed under Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International.

NETWAYS‘ Upcoming Training #Summer2018

Our Open Source trainings are designed to support your modern business processes

New Ways with NETWAYS – Our goal is to design your learning process as comfortable as possible! 


Foreman – Life Cycle Management for Servers
2 days training sessions | 03.07.2018 to 04.07.2018
CEPH – Scale out Storage
2 days training sessions | 03.07.2018 to 04.07.2018
GitLab – Modern Software Development
2 days training sessions | 10.07.2018 to 11.07.2018
Icinga 2 Fundamentals – Monitoring Redesigned
4 days training sessions | 10.07.2018 to 13.07.2018
Bareos – Level 1 – Introduction to Bareos
3 days training sessions | 16.07.2018 to 18.07.2018
Graylog training – Centralized Logfile Management
2 days training sessions | 17.07.2018 to 18.07.2018
Bareos – Level 2  – Backup with LTO
2 days training sessions | 19.07.2018 to 20.07.2018
Ansible  Configuration Management
2 days training sessions | 24.07.2018 to 25.07.2018
Ansible AWX (Tower) 
1 day training session | 26.07.2018


For the whole NETWAYS training schedule visit: netways.de/training. For assistance please contact us.

Keya Kher
Keya Kher
Marketing Specialist

Keya ist seit Oktober 2017 in unserem Marketing Team. Nach ihrer Elternzeit ist sie seit Februar 2024 wieder zurück, um sich speziell um Icinga-Themen zu kümmern. Wenn sie sich nicht kreativ auslebt, entdeckt sie andere Städte oder schmökert in einem Buch. Ihr Favorit ist “The Shiva Trilogy”.