DevOps

2010 readers
3 users here now

DevOps integrates and automates the work of software development (Dev) and IT operations (Ops) as a means for improving and shortening the systems development life cycle.

Rules:

Icon base by Lorc under CC BY 3.0 with modifications to add a gradient

founded 2 years ago
MODERATORS
51
 
 

GitHub only supports a single CODEOWNERS file in a repository, which is fairly limiting. This tool allows OWNERS files to be distributed throughout the code base, and provide more localized semantic meaning.

Benefits of distributed files:

The primary benefit, in my view, is around ownership of the CODEOWNERS file. Having a single file means that you either have a small number of people who own the CODEOWNERS file, through which all updates must pass, or you have the CODEOWNERS file open broadly, possibly to anyone's reviews. In the former, you have a bottleneck, and people approving changes they may not be familiar the implications of, especially cross team ownership. In the latter, people could add themselves as an owner without the current owners being aware. By having the distributed OWNERS files, the teams/people who own the code also own the OWNERS file. This means the right people will have to approve changes.

It's easier to find who the experts on a group of code is, which is helpful when people have questions, or are otherwise seeking to engage more about it.

It's generally better practice to have many smaller scoped files, rather than monolithic ones. This applies to code, of course, but it also applies to metadata, such as ownership.

Feedback is welcome, I hope some find this helpful. :)

https://github.com/andrewring/github-distributed-owners

Note this includes support for pre-commit.

52
 
 

cross-posted from: https://lemmy.ml/post/4593804

Originally discussed on Matrix.


TLDR; Ansible handlers are added to the global namespace.


Suppose you've got a role which defines a handler MyHandler:

- name: MyHandler
  ...
  listen: "some-topic"

Each time you import/include your role, a new reference to MyHandler is added to the global namespace.

As a result, when you notify your handler via the topics it listens to (ie notify: "some-topic"), all the references to MyHandler will be executed by Ansible.

If that's not what you want, you should notify the handler by name (ie notify: MyHandler) in which case Ansible will stop searching for other references as soon as it finds the first occurrence of MyHandler. That means MyHandler will be executed only once.

53
54
 
 

OpenTF fork (prepare for alpha) is now available at the GH Repository here:

https://github.com/opentffoundation/opentf

Take a look at the issues tab to see some of the live RFCs and discussions happening. Lots of things like the use of tf in the binary/name and bring their own registry.

55
56
 
 

TLDR: terraform bad, pulumi good

57
58
 
 

Is your organization doing anything to ensure new devs are productive from day one? How do you guys handle local environments for the code you are working on? I am trying to get my company to enable teams to create their own workstation image that contains all the dev tools and local application-related infrastructure needed for that team to be productive. Has anyone done something similar?

59
 
 

Both are valuable, but which should be the priority? Assuming finite hours in a day, how much time should be spent working on your actual work vs. learning about the customer vs. learning about technology you haven't worked with before?

60
 
 

Here's a hypothetical scenario at a company: We have 2 repos that builds and deploys code as tools and libraries for other apps at the company. Let's call this lib1 and lib2.

There's a third repo, let's call it app, that is application code that depends on lib1 and lib2.

The hard part right now is keeping track of which version of lib1 and lib2 are packaged for app at any point in time.

I'd like to know at a glance, say 1 month ago, what versions of app is deployed and what version of lib1 and lib2 they were using. Ideally, I'm looking for a software solution that would be agnostic to any CI/CD build system, and doubly ideally, an open source one. Maybe a simple web service you call with some metadata, and it displays it in a nice UI.

Right now, we accomplish this by looking at logs, git commit history, and stick things together. I know I can build a custom solution pretty easily, but I'm looking for something more out-of-the-box.

61
 
 

Won't impact most users apparently.

62
63
64
65
66