www-gitlab-com VS troposphere

> 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...

Seems like an interesting generalized mix of something like https://github.com/cloudtools/troposphere and Ansible from a glance.

The value add would be unifying provisioning and configuration management in a Python-y experience? The lifecycle of each is distinct and that's traditionally where the headaches of using a single tool for both has come in

Under the IaC category, in July 2023, AWS added loops to CloudFormation, finally ticking a box the community has been asking for since troposphere. I suspect that, in combination with the Terraform licensing changes, it may keep people using CloudFormation for a while longer.

Because ECS Compose-X uses Troposphere, I was able to create a very light and simple python library(https://github.com/JohnPreston/troposphere-awscommunity-applicationautoscaling-scheduledaction) to distribute the resource for other Troposphere users to re-use.

Written in house, but the library troposphere is the primary component of how it is built. Example stacks are here.

I am kind of going off topic here, but isn't the point of being an SA to be created with code services to deliver solutions at scale that are cost-effective? How in the hell can you do that when you can't write a simple Python template that generates code at 50 times the rate you can manually? How can you ever be expected to deploy a serverless solution if you can't write any code yourself? There has to be some level of proficiency there.

Wouldn't using troposphere[1] be easier?

[1] https://github.com/cloudtools/troposphere

You might have seen some tutorials on how to set up S3 buckets using the AWS Console. This works fine, but I'm a firm believer of managing your resources with code. I've chosen the native solution of AWS, called AWS CloudFormation. This makes it easier to reproduce the setup if I ever need to tear it down of move it to another account or region. Below is the full CloudFormation template, I've used a framework called Troposphere, a Python library that creates CloudFormation.

For CF for example I no longer write template in yaml or shudders json, and instead I use troposphere.

refer : https://github.com/cloudtools/troposphere