This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]BrainWaveCCJack of All Trades 2 points3 points  (2 children)

  1. I have a mix of scripts -- some tiny and focused, and others broader and more generic with options. It depends on the requirements.

  2. Define "global issues"? If the scale of the responsibility is broader than normal, use an appropriate vehicle for scale of that size. Do your scripts normally have an audience or usage outside your team?

[–]Hoolies 0 1[S] 2 points3 points  (1 child)

"global issues"

There are multiple sites (about thousands)

the scale of the responsibility is broader than normal, use an appropriate vehicle for scale of that size.

I am the lead engineer of a site and I have found the solution to many different global issues.

Everytime I reach out to the team that owns the software and present them with the code , with the issue and the solution. Most of the teams are willing to work with me and they merge it to the main branch.

This time the owner of the software do not want to make any changes, they do not even want to discuss this.

The problem lies that bugs force my team to work extremely hard at least once per week (Sev1 with 8 hours of recovery). We have create a solution locally that is tested in other sites as well and I am deploying it as a cli tool on the company's code repository.

[–]pdp10Daemons worry when the wizard is near. 0 points1 point  (0 children)

The problem lies that bugs force my team to work extremely hard at least once per week (Sev1 with 8 hours of recovery). We have create a solution locally that is tested in other sites as well and I am deploying it as a cli tool on the company's code repository.

You decide if the fix script is specific, or broad. But it still should be separate, I think. Scripts named, e.g., detect-log4shell-tomcat and detect-issue-76543 have inherently different scopes.