observability VS www-gitlab-com

GitLab team member here, putting my personal hat on - from my experience in using different Git workflows since 2009, a smaller clean unit of work can with debugging and troubleshooting. It also provides a way to new team members and contributors to understand the thought process and ideation to implement a new architecture, apply performance fixes, add documentation, work with tests, additional fixes, until its final release. Most of this can be tracked within a MR/PR and the history of code reviews, etc. - even after the merge and squash and Git branch delete, not trying to argue with this functionality. :)

From the Git CLI, without any reference to Git* platforms, it is not so obvious when searching for a commit that introduced a bug, e.g. using "git bisect" for binary search. Reading a 10,000 lines git diff can be harder than a smaller commit that also explains the reasoning in the commit message. Speaking from own experience and programming mistakes in a small team, focussing on clean commits and a good history tremendously helped in stressful debug situations. Until you hit a compiler regression bug, but that's a different story then ;)

I'm personally still very fast on the Git CLI, but I also know that there are a variety of CLI and UI tools out there that can help with analysing large Git commits. Potentially in the future also AI assisted that tell us which change a diff caused a performance regression in a release 5 months later. Or we don't need it at all because Observability driven development enabled to see these problems before merging and code reviews, e.g. the memory leak but only when DNS fails. True story from ~2016, more in my KubeCon EU talk at https://www.youtube.com/watch?v=BkREMg8adaI and project at https://gitlab.com/everyonecancontribute/observability/cpp-d...

GitLab team member here, thanks for sharing!

I'm using the Web IDE to take notes in most of my projects, work and personal, and publish the notes with MkDocs and GitLab Pages to a searchable frontend/domain when needed. Editing also happens in Gitpod with live preview in the browser.

You can find all resources for o11y.love [0] and opsindev.news [1] in the GitLab projects, including .gitpod.yml configuration, mkdocs.yml setup, .gitlab-ci.yml deployments.

I have been writing lots of documentation in my past OSS projects, so I am used to Markdown as markup language, taking notes very fast. Learning Markdown requires some practice, and can be helped within Gitpod and the VS Code extensions, if the default preview is not sufficient. [2] [3] You can also sync the notes repository offline into VS Code as desktop IDE for example.

Using Obsidian.md to take notes and publish with GitLab pages [4] looks promising too; I have not tried it yet.

[0] https://gitlab.com/everyonecancontribute/observability/o11y....

[1] https://gitlab.com/dnsmichi/opsindev.news

[2] https://www.gitpod.io/docs/ides-and-editors/vscode-extension...

[3] https://code.visualstudio.com/docs/languages/markdown

[4] https://about.gitlab.com/blog/2022/03/15/publishing-obsidian...

> Whatever spark they were feeling in the moment would be sufficiently stomped when they notice the first step in the tutorial is to create a Makefile. Keep in mind they also introduce the concept of variables and if statements. This tutorial's aimed at total beginners!

Thanks for your great feedback. I suggested using a Makefile during blog post review [0], to avoid explaining gcc compiler flags, and have a single command with `make build` available for future, repeated compilation steps. I did not expect this to be an entry barrier, and will reconsider suggesting makefiles in the future. Thanks again.

[0] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

(GitLab team member here)

Wow, thanks a lot for sharing. GitLab team member here.

Would it be ok for you if I add that command snippet into a blog post I am currently writing about Observability for Efficient DevSecOps Pipelines? Draft MR is in https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/34296 Thanks!

Regarding pipeline visibility and traces: I would love to see the same :-) I tested tracepusher with OpenTelemetry this week, and the timeline for CI/CD traces is a great start in Jaeger. Added a suggestion into https://gitlab.com/groups/gitlab-org/-/epics/5071#note_14582... where CI/CD Visibility is being worked on, with an update on GitLab support for traces in https://gitlab.com/groups/gitlab-org/-/epics/5071#note_14584...

GitLab team member here. Thanks for your feedback.

> But IMO there are plenty of other places to add real value across the GitLab product with AI/ML features.

True, and after starting with ML experiments, the product and engineering teams have been working on new features for entire DevOps lifecycle. All AI workflows on the DevSecOps platforms are described in the GitLab Duo announcement blog post https://about.gitlab.com/blog/2023/06/22/meet-gitlab-duo-the... and website https://about.gitlab.com/gitlab-duo/

I'll share a few highlights that I am personally excited about

- Explain and help fix security vulnerabilities. From my personal experience, I often find CVEs hard to read, especially when I am not the author of the code to fix. Getting help from AI can reduce entry barriers and make development for efficient. Security is everyone's responsibility these days. This follows the AI assisted feature to explain code in general. "What does this magic loop with memcpy do?" might not stay magic anymore, easing the path to code refactoring, improving performance, and reduce the resource usage footprint.

- Summarize issue comments. Feature proposals or bug analysis can have long comment threads that require reading time. AI will help get the gist and better contribute to what has been discussed.

- Summarize MR changes, to avoid reading long change diffs. This helps with faster (code) review cycles. I tested it this week with an MR for our handbook in https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

I'd also like to see AI helping fix CI/CD pipelines fast. Proposal in https://gitlab.com/gitlab-org/gitlab/-/issues/386863 I shared some thoughts in a new talk "Observability for Efficient DevSecOps Pipelines", slides in https://go.gitlab.com/VDAvMw (GitLab blog post coming soon, https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/34296)

Additionally, I learned some new ideas at Cloudland last week, regarding product owner requirements list verification, and end-to-end test automation with AI. Need to create feature proposals :-)

> As a longtime GitLab user (and onetime contributor!),

Thanks for contributing. I'd like to invite you to share your ideas about AI features across the platform :)

When you look at the DevOps lifecycle (image in https://about.gitlab.com/gitlab-duo/) from plan/manage to create, verify, secure, package, release, deploy, monitor, govern - where do you see yourself, and where do you spend the most time in?

Second question: Which process feels the most inefficient? After identifying answers to the questions, please check the AI features https://docs.gitlab.com/ee/user/ai_features.html and/or open new feature proposals for GitLab https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_t... You can tag @dnsmichi so I can engage with your ideas. Thanks!

Tangentially related: One can store SSH server host keys in DNS and tell the client to make use of them. This is an alternative to the client asking the user to confirm the server host key, which many people just blindly confirm.

I asked GitLab if they could make use of that, but it hasn't received much attention so far:

* https://gitlab.com/gitlab-com/www-gitlab-com/-/issues/10376

Thanks a lot for helping :-)

I've created an MR to link MVC in the handbook: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

(GitLab team member here)

Why not? Gitlab keeps their entire employee handbook in a Git repo.

GitLab team member here.

Sharing a personal insight - I'm currently moving flats in the Nuremberg area in Germany which is a little hectic because forced out by the new house flat owner. Async work enables me to take calls and go shopping to organize the move, whilst shifting work hours into the evening or early morning. I am also able to take paid time off (PTO) when needed to prepare the move early December. In my previous office job, I would have needed to reserve a lot of vacation days for this, and ask for permission to start later than 10am, or after 4pm. Here at GitLab, I am my own manager [0] and take care about my working hours - it is a personal freedom, and I appreciate these less stressful times a lot. In return, I can take time to focus on private life, and come back refreshed to produce great results (blog posts, talks, helpful replies here and other community channels, etc.).

What I learned in the past 2 years and 9 months at GitLab, is to provide as much context as needed so that someone else in a different timezone can continue async, and is not blocked by anything (low context communication [1]). Also, short toes [2] enable everyone to add their thoughts and opinions, and work with the directly individual responsible (DRI) for the best outcome.

The Slack retention period of 90 days is a great reminder (and also enforcement) to document everything in the handbook. Example from today: I learned that Google docs supports the colon for emoji live-search. Thought of sharing in Slack, but then went with editing the handbook and sending a MR [3] to help everyone find this little efficiency tip in the future - that said, Slack is not a knowledge base. The GitLab handbook is.

Thinking about the past year with a public discussion about speaker diversity at events, I admire our teams to take action to ensure events align with our diversity, inclusion and belonging values. We have updated our event requirements for speakers (MR [4], handbook page [5]), and are working with event organizers and the wider community to help with mentoring and coaching to inspire future speakers.

Last but not least, transparency [6]. Internal and external, I can read and learn async at my own pace. Most of my meetings are optional, and the meeting notes/recording are detailed, with follow-up actions. You'll never recap old meeting notes the next time but reference actioned issues and merge requests. Many issues/epics are public - if you'd like to learn more about my thought leadership strategy for Observability, and all content created and planned, you can follow this epic [7] or my profile activity [8] for example.

I haven't met everyone in-person yet, because of the pandemic, and travel only for some events (KubeCon EU/NA, PromCon EU [9] [10]), but I am looking forward to meet and value these moments. Hard to describe, I feel incredibly connected to my teams albeit living far far away. :-)

Happy to share more thoughts and insights - my role is on the community relations/developer evangelism team, I'm the stable counterpart for the product teams, and collaborate in cross-functional initiatives often. [11] My first [12] and second [13] year blog posts share more experiences too :-)

[0] https://about.gitlab.com/handbook/leadership/#managers-of-on...

[1] https://about.gitlab.com/handbook/communication/#effective-c...

[2] https://about.gitlab.com/handbook/values/#short-toes

[3] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

[4] https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

[5] https://about.gitlab.com/handbook/marketing/corporate-market...

[6] https://about.gitlab.com/handbook/values/#transparency

[7] https://gitlab.com/groups/gitlab-com/marketing/-/epics/2593

[8] https://gitlab.com/dnsmichi

[9] https://dnsmichi.at/2022/06/13/my-kubecon-eu-experience-firs...

[10] https://opsindev.news/archive/2022-11-23/#promcon-eu

[11] https://about.gitlab.com/handbook/marketing/community-relati...

[12] https://dnsmichi.at/2021/03/02/my-1st-year-all-remote-at-git...

[13] https://dnsmichi.at/2022/03/02/2-years-all-remote-and-2022-v...

Today I learned, thanks a lot!

Created a MR for the Developer Evangelism Hacker News handbook to add this formatting tip, and some more https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...

As a shadow, you would contribute anywhere, not just on the CEO Shadow process.

I see them often on slack updating various random pages:

https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_request...