Ranter
Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Comments
-
GreenHat1258ySo where you work you can get fired just like that from one day to the other because of a mistake?
-
Maybe the source control repository and the CI/CD pipeline should be RBAC secured so that "mistakes" cannot happen. Maybe, just maybe, the person in charge of TFS should ensure that it is compliant with the architected processes.
-
My opinion... sounds like pretty much common sense that if you are working with specific organized branches and there is no history of direct modifications to the main (only merges), then you shouldn't ever mess with the main.... I would have asked for clarification on missing files and the merge issue and what is best practice during that specific scenario, instead of assuming the quickest solution to avoid confrontation, is the best one.... cause remember that everyone else now has to merge main with their own branches (respectively, unless you went around to every branch and merged main into them already).... my conclusion, the TFS template or whatever seems bugging and in efficient, but also it's good recognize that these 'higher ups' always have a model, goals, and path that they are trying to follow and maintain that the lower devs in the business hierarchy don't know or may never no about.
-
KalmyK4798yI mean, honesty, I hate people like you ;) no offense. People like you usually break ci/cd pipelines without understanding of version control. At the same time, that muggle with document can fuck off and educate you like a normal person. And yeah, you can bend rules when there is an exception, but it always needs a second pair of eyes.
-
@GreenHat A place where the manager doesn't like you. My nickname is/was the 'Rule Breaker'. I still violate the rules, not because I don't think think they are not important, but because we're here to serve people. That's it. When a rule gets in the way of serving our customers, I knock it out of the way.
It is a philosophy the CEO has on posters throughout the campus. Customers are our #1 value. Over the past 20 years, I've 'out lived' many managers who ended up on the wrong side of choosing to follow the rules, or serve the customer.
Yes, if you're curious, the manager in question was fired for trying to push policy over people. -
@KalmyK No offense taken. The kingpin had waaay too many control issues and made our pipeline far too complex for what was needed.
Since his firing, we've greatly simplified the process. I was 'promoted' to his spot and his daily tasks where delegated throughout the teams.
Didn't do anything except ask 'Why?'
"Why do we have 4 branches for every project?"
When the only answer is "um...uh...um....best practice?", the solution presented itself and now our RC/CI build processes are automated and streamlined (probably like most, nothing special)
I think it's been a year since anyone has had any source control issues. -
@williegroovy
TFS = Microsoft's Team Foundation Service. A source control repository.
Related Rants
-
DivByZero9During a software presentation for a group of clients i said: "I reworked the interface for you. Now it's idi...
-
gurumeditation14Not me, but a colleague of mine ordered 10,000 pens with <company>.com printed on them - but our company had a...
-
darshan23038Client asked to change the shade of blue to a little lighter shade. Deleted the hex code and typed the same he...
I've had many, but this is one of my favorite "OK, I'm getting fired for this" moments.
A new team in charge of source control and development standards came up with a 20 page work-instruction document for the new TFS source control structure.
The source control kingpin came from semi-large military contract company where taking a piss was probably outlined somewhere.
Maybe twice, I merged down from a release branch when I should have merged down from a dev branch, which "messed up" the flow of code that one team was working on.
Each time I was 'coached' and reminded on page 13, paragraph 5, sub-section C ... "When merging down from release, you must verify no other teams are working
on branches...blah blah blah..and if they have pending changes, use a shelfset and document the changes using Document A234-B..."
A fellow dev overheard the kingpin and the department manager in the breakroom saying if I messed up TFS one more time, I was gone.
Wasn't two days later I needed to merge up some new files to Main, and 'something' happened in TFS and a couple of files didn't get merged up. No errors, nothing.
Another team was waiting on me, so I simply added the files directly into Main. Unknown to me, the kingpin had a specific alert in TFS to notify him when someone added
files directly into Main, and I get a visit.
KP: "Did you add a couple of files directly into Main?"
Me:"Yes, I don't what happened, but the files never made it from my branch, to dev, to the review shelfset, and then to Main. I never got an error, but since
they were new files and adding a new feature, they never broke a build. Adding the files directly allowed the Web team to finish their project and deploy the
site this morning."
KP: "That is in direct violation of the standard. Didn't you read the documentation?"
Me: "Uh...well...um..yes, but that is an oddly specific case. I didn't think I hurt any.."
KP: "Ha ha...hurt? That's why we have standards. The document clearly states on page 18, paragraph 9, no files may ever be created in Main."
Me: "Really? I don't remember reading that."
<I navigate to the document, page 18, paragraph 9>
Me: "Um...no, it doesn't say that. The document only talks about merging process from a lower branch to Main."
KP: "Exactly. It is forbidden to create files directly in Main."
Me: "No, doesn't say that anywhere."
KP: "That is the spirit of the document. You violated the spirit of what we're trying to accomplish here."
Me: "You gotta be fracking kidding me."
KP grumbles something, goes back to his desk. Maybe a minute later he leaves the IS office, and the department manager leaves his office.
It was after 5:00PM, they never came back, so I headed home worried if I had a job in the morning.
I decided to come in a little early to snoop around, I knew where HR kept their terminated employee documents, and my badge wouldn't let me in the building.
Oh crap.
It was a shift change, so was able to walk in with the warehouse workers in another part of the building (many knew me, so nothing seemed that odd), and to my desk.
I tried to log into my computer...account locked. Oh crap..this was it. I'm done. I fill my computer backpack with as much personal items as I could, and started down the hallway when I meet one of our FS accountants.
L: "Hey, did your card let you in the building this morning? Mine didn't work. I had to walk around to the warehouse entrance and my computer account is locked. None of us can get into the system."
*whew!* is an understatement. Found out later the user account server crashed, which locked out everybody.
Never found out what kingpin and the dev manager left to talk about, but I at least still had a job.
undefined
wk50