GitHub Actions


GitHub today released a CI/CD Tool, GitHub Actions. With the tight integration into development workflows and rich, community maintained build-command, actions appears an interesting competitor in the market. As a minimum, the release indicates the importance of CI/CD for the modern software development lifecycle.

Developer productivity and frictionless workflows have been buzzwords for the past half decade and the arrival and rapid growth of Travis-CI, Jenkins or Cirlce-CI have proven the resonance in development organisations. GitHub has outstanding testimonials from day one on the announcement and the ecosystem appears to be ready to go.

It is an offering that comes with appealing integrations and a competitive price, that sure is worth watching.

GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub. Make code reviews, branch management, and issue triaging work the way you want.

Product Management vs Product Ownership

The organisation that I am part of introduced an overlaying Product Management department only fairly recently, less than a year ago. Early in the time it was exciting to see this role dedicated to market and customer perspective, but it raised questions over how this was different from Product Ownership from day one.

Over the course of the past year many discussions have been led and lot’s of articles have been led. This week Anthony Murphy shared his perspective and experiences on the Product Coalition. While my own experiences with this separated role have been predominantly positive, I tend to see the necessity to split responsibilities for larger organisations. The article is reflecting on why the Agile movement created the Product Owner in the way it did and how it was meant to abolish the Product Manager to start with.

A story of love, hate, oppression and triumph

Source: The Collision of Product Management and Product Ownership

GitHub announces Package Registry

Your code. Your packages. One login. Meet GitHub Package Registry.

From the announcement on LinkedIn
Octocat Package Registry

The other day wrote this in their post on LinkedIn. Following the link takes one to the newly announced Github Package Registry, that allows developers to host releases for distribution. It’s currently in beta and supports npm, docker images, maven packages, NuGet and Ruby Gems. The corresponding blog article has a few more insights:

With GitHub Package Registry your packages are at home with their code—sign up for the limited beta to try it out.

From the blogpost

While I appreciate the thought and easiness of integration, the announcement doesn’t leave me with a cosy feeling. It’s a bit like GitHub is trying to become the Facebook of code. The Internet is made to work decentralised and the interesting part always has been the freedom of choice. With functionality merging together in one platform, choice gets lost and there is opportunity of misuse.

In particular, it seems almost forgotten that Github, just like Linkedin, have been acquired by Microsoft in 2016 and 2018. This perspective throws another light on the added functionality and developers may want to evaluate remaining alternatives.

Source: Introducing GitHub Package Registry – The GitHub Blog

Infosec community

Gerade brennt eine Security Diskussion darum, dass Videolan Updates für seinen Mediaplayer nur über http:// ausliefert. Auch meiner Meinung nach entspricht das nicht dem Standard von 2019, aber hey. Wohl hatten die Entwickler verschiedene Argumente, an dem Verfahren festzuhalten. Signaturen via gpg, Maintenance, Aufwand und so.

Jedenfalls eröffnet die Situation eine spannende Diskussion darüber was denn nun das richtige Vorgehen ist und vor allem: wer denn nun Recht hat. Die Videolan Community jedenfalls scheint die Kollegen von Infosec nicht sehr sympathisch wahrzunehmen.

Aus meiner professionellen Erfahrung muss ich leider konstatieren: auch anderswo gibt es keineswegs einen Zusammenhalt von Dev und Sec. Die Wahrnehmung wird in vielen Softwareentwicklungsteams sehr ähnlich sein. Viel mehr ist das ein ständiges sich gegenseitig sich anpöbeln. Ganz ähnlich wie in der beschriebenen Fall.

Das ist sogar nachvollziehbar weil es zwei Parteien sind, die individuelle Interessen vertreten. Und es gibt aus der Situation in der Regel auch keinen vernünftigen Ausweg, weil die Incentivierung der Teams nicht das gleiche Ziel anstreben. Security ist damit Teil eines Problems und nicht Teil einer Lösung.

“So könnt Ihr das nicht machen” eröffnen die einen, deren Auftrag es ist, Fehler in Software zu finden. “Hey, wir haben uns da Monatelang was dabei gedacht” halten Entwickler dann dagegen und schon ist die Debatte in vollem Gang.

Gerade weil in der Regel das Aufgabengebiet der Security Kollegen sich darauf beschränkt, Fehler aufzuzeigen, ist es für die gegenüber stehende Partei nur nachvollziehbar, jedes Audit als Quelle für zusätzliche, oft kaum nachvollziehbare Arbeit oder sogar Schikane wahrzunehmen.

Wenn Infosec auch einen Weg aufzeigen kann, der mit der Situation der Entwickler vereinbar ist, gelingt es sichere Software zu schreiben. Nur Fehler aufzuzeigen ist dafür zu wenig.

Im Fall von Videolan wird die Debatte nun öffentlich geführt, was nicht sehr schön zu verfolgen ist, aber es ist eine notwendige Debatte für jede tiefere Integration von Development und Security.