|
I just rewrote a little internal command line tool into a proper/native windows desktop app, took about 4 hrs over 2 days, it was fun. Now I’m completely deflated at the prospect of deployment; generating a single file executable, dealing with versioning, signing the exe in the Azure DevOps pipeline, having the pipeline copy the artifact to the storage account, serving the file with proper permissions, etc. All the stuff that isn’t Writing The Code always sucks all the time.
|
#
?
Jun 29, 2023 17:39
|
|
|
|
| # ? May 10, 2024 00:26 |
|
|
Just make sure you automate that bullshit so when they want you to make changes Wednesday next week you don't have to do it all by hand again!
|
|
#
?
Jun 29, 2023 17:55
|
|
|
I would prefer to design the app, tell someone else to code it, review their code and then fix all the devops poo poo myself. I get bogged down in everything being "perfect" when coding so it just takes way too long.
|
|
#
?
Jun 29, 2023 21:52
|
|
|
Man, someone should get all you guys into one organization and assign you different titles based on which part of the workflow you are handling
|
|
#
?
Jun 29, 2023 22:14
|
|
|
epswing posted:I just rewrote a little internal command line tool into a proper/native windows desktop app, took about 4 hrs over 2 days, it was fun. I do a lot of sysops style coding in my team, and the thing that absolutely sucks the life out of me more than anything else is loving permissions. At my BigTech company, questions like 'how do we determine what framework a given service is using' turns into a nightmarish list of Microservices, all of which have their own dumb permissions model, onboarding systems, clients, and use cases/etc. My favorite part is that by and large, we separate permissions into Are You A Human or Filthy Robot Scum. For humans, this isn't SO bad; there's a whole system where human-driven interactive stuff can easily inherit the user's permissions that are generally easier to manage and tends to also grant access to the UX associated with a given API; so if you want to call the Service Configuration API, as long as you have perms to the Service Configuration Site, you're all good in the hood. Obviously you can still get into 'whoops need perms' but it tends to work out pretty fast. But sometimes that's not the case, and for poo poo that ABSOLUTELY should be. For example, we have an old rear end alarming platform that's used EVERYWHERE, and for some godforsaken reason it does not support the Human Auth model and only uses service auth models...and service auth models are (for probably good reasons) a loving pain in the rear end nightmare space. So if a human wants to do things like 'crawl through our alarms and see what's up' you need to basically use the service-auth model on your personal VM and then call using that. I also love onboarding when it's like 'what is the expected TPS' and I'm like 'I dunno man I'm gonna run this like a couple dozen loving times so maybe 150 TOTAL REQUESTS EVER YOU FUCKS BECAUSE YOU loving UX IS A NIGHTMARE I CAN'T TIE INTO AT ALL" Anyway all of that sucks and I hate it. We should go back to usernames and passwords for everything and passwords must always be Password1.
|
|
#
?
Jun 30, 2023 01:54
|
|
|
I can't seem to find this page of the thread, what is going on?
|
|
#
?
Jun 30, 2023 11:19
|
|
|
Cup Runneth Over posted:Man, someone should get all you guys into one organization and assign you different titles based on which part of the workflow you are handling Nah, it's now mandatory that everyone be able to own their entire stack. So the infrastructure and DevOps guy is trying to figure out how the gently caress CSS works, the react guy is trying learn how to write SQL, and the C# guy isn't quite sure what terraform is, but he'll figure it out eventually.
|
|
#
?
Jun 30, 2023 14:22
|
|
|
old project that I recently left had me doing frontend, backend, databases, elasticsearch, devops, cloud admin, networking, answering user emails, had a rotating desk where they wanted people coming to the office so the scientist-programmers could ask questions, etc shortly after changing projects I got inadvertently included in a meeting invite to some of the devs titled "Help Desk Shift" lmao 
|
|
#
?
Jun 30, 2023 15:23
|
|
|
Carbon dioxide posted:I can't seem to find this page of the thread, what is going on? Just keep refreshing 
|
|
#
?
Jun 30, 2023 15:37
|
|
|
Fellatio del Toro posted:old project that I recently left had me doing frontend, backend, databases, elasticsearch, devops, cloud admin, networking, answering user emails, had a rotating desk where they wanted people coming to the office so the scientist-programmers could ask questions, etc https://www.youtube.com/watch?v=F2Z2CklSxM0
|
|
#
?
Jun 30, 2023 15:41
|
|
|
Fellatio del Toro posted:shortly after changing projects I got inadvertently included in a meeting invite to some of the devs titled "Help Desk Shift" lmao
|
|
#
?
Jun 30, 2023 15:45
|
|
|
epswing posted:Now I’m completely deflated at the prospect of deployment; generating a single file executable, dealing with versioning, signing the exe in the Azure DevOps pipeline, having the pipeline copy the artifact to the storage account, serving the file with proper permissions, etc. It's funny because the idea on paper is that they're taking work off your hands, but sometimes it's just boxing you into their particular workflow with no ability to change it.
|
|
#
?
Jul 4, 2023 00:15
|
|
|
steckles posted:We get this every now and then. Parts of our code base are over 20 years old and sometimes a newish developer will get all "Let's rewrite this in PHP" Nobody is saying this. Please tell me nobody is saying this.
|
|
#
?
Jul 4, 2023 19:16
|
|
|
A guy said that at my previous job and I had to say "absolutely not" a few times before he realized I was serious
|
|
#
?
Jul 4, 2023 19:46
|
|
|
PHP has static types and is way faster than Python
|
|
#
?
Jul 4, 2023 20:23
|
|
|
eXXon posted:Nobody is saying this. Please tell me nobody is saying this.
|
|
#
?
Jul 4, 2023 21:24
|
|
|
God I love being treated like a resource and tasked with poo poo that is irrelevant to my skill sets and job title especially when there is already an appropriate party to handle the task. Not to mention I am single-handedly working on a potential client integration which means lots of revenue if it succeeds by a specific date. We can put that on pause right? No? Then why did you ask me to do this!?
|
|
#
?
Jul 5, 2023 16:11
|
|
|
Sounds like a failure of management to me. Unfortunately management can’t fail, it can only BE failed, you fuckin peon!!!!
|
|
#
?
Jul 5, 2023 16:22
|
|
|
He said he wants to have it in this sprint, to which I replied "I already have work this sprint, so we can discuss adding this work in the next sprint planning." 
|
|
#
?
Jul 5, 2023 16:39
|
|
|
Fondly remembering when I finally won the battle that they should be giving me architectural tasks and not an endless series of "adjust the padding on the Fart button" tasks and a little while later they laid me off because "we don't need an architect"
|
|
#
?
Jul 5, 2023 16:54
|
|
|
Anyone got any thoughts on trunk based development? Hot? Or not?
|
|
#
?
Jul 9, 2023 14:47
|
|
|
I hate long running branches with a passion
|
|
#
?
Jul 9, 2023 14:56
|
|
|
I think it makes a lot of sense especially paired with feature branches. Makes Ci/CD pretty straightforward as well
|
|
#
?
Jul 9, 2023 15:01
|
|
|
Macichne Leainig posted:I think it makes a lot of sense especially paired with feature branches. Makes Ci/CD pretty straightforward as well Isn't it more or less the opposite of feature branches?
|
|
#
?
Jul 9, 2023 15:07
|
|
|
prom candy posted:Anyone got any thoughts on trunk based development? Hot? Or not? My current place does this, I’m a convert. Merge problems are smaller, and a great mechanism for finding out that some other team is also active in an area RIGHT NOW and you should go talk to them before spending weeks working on something.
|
|
#
?
Jul 9, 2023 15:20
|
|
|
prom candy posted:Isn't it more or less the opposite of feature branches? feature branches exist, but they are short lived, only active as long as you are working on that feature, and all merge into main
|
|
#
?
Jul 9, 2023 15:23
|
|
|
And then you can do all your CI/CD stuff on the merge PR. Works real nice imo
|
|
#
?
Jul 9, 2023 15:26
|
|
|
this is contrasted to gitflow where you maintain a longer term dev branch (and staging and hotfix etc) and your feature branches merge into those, while those merge into your main branch only for releases
|
|
#
?
Jul 9, 2023 15:27
|
|
|
prom candy posted:Anyone got any thoughts on trunk based development? Hot? Or not? I find that the trunk is too large to type effectively with.
|
|
#
?
Jul 9, 2023 15:49
|
|
|
The Fool posted:this is contrasted to gitflow where you maintain a longer term dev branch (and staging and hotfix etc) and your feature branches merge into those, while those merge into your main branch only for releases I was very proud one day when my coworker who was working on converting an SVN repo to Git asked me about all this gitflow and branches stuff and I got to say, "There's only two of you working occasionally in this repo. Just ask each other before making big changes."
|
|
#
?
Jul 9, 2023 16:52
|
|
|
The Fool posted:this is contrasted to gitflow where you maintain a longer term dev branch (and staging and hotfix etc) and your feature branches merge into those, while those merge into your main branch only for releases why the gently caress would you do that?
|
|
#
?
Jul 9, 2023 19:41
|
|
|
Xarn posted:why the gently caress would you do that? Because in a Large Organization, the expectations of upstream/downstream teams will have many small adjustments as the overall Product feature is being developed, the managers want to save money on the development environment, decades of tech debt and painful Major Incidents prevent you from having any CICD at all, and deployment as a process takes an entire day because of knowledge silos even for the components that your team owns due to lack of documentation and knowledge transfer as people leave the company and go elsewhere.
|
|
#
?
Jul 9, 2023 20:01
|
|
|
Yeah I've only ever operated with a trunk-based model; the other ones seem totally byzantine to me. I suspect there's some software where it makes sense, but boy it seems like a nightmare. Like we just finished up a big milestone and so there was a flurry of merges there at the end, and sure, for that specific case it was frustrating to deal with merge conflicts, but at least you're generally only dealing with your conflicts, and it doesn't seem like gitflow would have solved that at all; someone would still have had to do all the merging.
|
|
#
?
Jul 9, 2023 20:02
|
|
|
prom candy posted:Anyone got any thoughts on trunk based development? Hot? Or not? It's the way to do it. I don't see why anyone would go with gitflow over trunk-based with short lived feature branches, it's a no-brainer upgrade in a world where CI/CD exists.
|
|
#
?
Jul 9, 2023 20:24
|
|
|
Love Stole the Day posted:Because in a Large Organization, the expectations of upstream/downstream teams will have many small adjustments as the overall Product feature is being developed, the managers want to save money on the development environment, decades of tech debt and painful Major Incidents prevent you from having any CICD at all, and deployment as a process takes an entire day because of knowledge silos even for the components that your team owns due to lack of documentation and knowledge transfer as people leave the company and go elsewhere. That said, I currently work somewhere where releases involve literal paperwork and week long freezes.
|
|
#
?
Jul 9, 2023 20:26
|
|
|
No pull requests rules. The Senior with Opinions About Whitespace cannot waste his time on approvals. I can imagine a terrible scenario where my coworkers deployed poo poo code and hated speaking to each other. Trunk based would not work there. As a work life, heavy scrutiny and pulls requests are nice if you're anxious, new or want a chill job doing what you are told. On the other hand, trunk based forced my still very green self to think through problems, test, and ask for help if I needed it before deploying. I personally enjoy a faster pace. I found sitting on my hands between approvals and having to bug whoever was on approval duty grating.
|
|
#
?
Jul 9, 2023 20:52
|
|
|
The process I've been using for years is like a simplified git-flow, where we have main, develop, and feature branches. Main should represent what's currently on prod, and develop represents what's on staging. Feature branches are created out of and merged back into develop, and then to do a release we merge develop into main. It works okay except if we go a while without releasing then merges back to main can be a bit scary as we start to forget what's even in there. The other problem is sometimes we do have long running feature branches and that's even worse. The trunk based dev stuff I was reading about all recommended merging feature branches back into main no less frequently than every day and making use of feature flags to just hide in-progress work. If we got rid of the develop branch I'm not sure how we'd handle staging though. I guess we'd make tagged release branches off of main and release those to prod, and staging would always be consistent with main? Edit: ^^^ I like PRs because I like people to have a view into what I'm working on and having a view into what they're working on. gently caress nitpickers though.
|
|
#
?
Jul 9, 2023 21:12
|
|
|
shouldn't feature branches be made from main since it's the latest "clean" branch (fully or at least almost fully tested and working)
|
|
#
?
Jul 9, 2023 21:19
|
|
|
prom candy posted:
yeah ideally "sitting on your hands between approvals" doesn't happen because you've probably got PRs you can be approving or something im a big fan of trunk development for all the reasons already listed. the closest i got to git-flow was having a release branch that we'd merge and deploy every two weeks and i fuuuuucking hated it. i got stressed out every single time i had to be the person running it because what if we forgot to test something. would much rather the trunk style and continuous deployment so if something's going to break, you'll know within an hour or something when it goes to prod
|
|
#
?
Jul 9, 2023 21:21
|
|
|
|
| # ? May 10, 2024 00:26 |
|
|
Xarn posted:why the gently caress would you do that? A significant amount of shops don't have automated QA, or even a formal QA process. I've worked at places with 0% test coverage, at places with 0 DBAs on staff but 100+ SQL databases, and at one memorable place where the Principal Architect said that indexes slow down queries and should never be used. My last gig had the senior devops engineer not know how memory works on Linux and never set up horizontal scalability in AWS. A lot of places are like that. When you're hovering at 0 or -1 on the CMMI/CMMII scale, it's extremely comforting to have gitflow. You say "We're preparing to cut a release, clear the decks" and the scrum master (or whomever is build bitch) closes up PRs to develop. A head engineer or the TPO creates the release branch, it goes to "QA" and all of the devs hammer through the Excel spreadsheet of tests. Minor repairs occur. The majority of devs can continue to work on the main develop branch while QA does their thing, which could take a few days as databases are reset and tests run by hand, dipping into the release branch to repair as needed. git flow release finish handles the complex case of "merging two branches with --atomic" that elude a lot of people. It's all very sedate and comforting, especially if you're in agilefall and have no automation. Slows things down and makes it manageable. The other main benefit is repair in the past. People say they hate long loved branches but sometimes a release can be quarterly or longer. While develop has moved through a few sprints (and is comically unstable), bugs in release version 1.2.69 can be addressed in the past, again without having to think where the tag is, or getting your branch commands correct, or how many merge targets. You just git flow hotfix finish and magic happens. tl;dr: Immature shops with low git skills, slow development and release cadence, and no QA, that cannot fail forward quickly need some kind of branching model where it's "easy" to maintain repairs in the past manage releases. As competency goes up it becomes more of a drag and you abandon for a trunk based model.
|
|
#
?
Jul 9, 2023 21:22
|
|
