|
Hargrimm posted:Why would you pre create a merge request at the beginning of feature development before you are ready to request the code be merged? It's a good way to get incremental feedback from people.
|
#
?
Nov 11, 2019 19:19
|
|
|
|
| # ? May 26, 2024 16:56 |
|
|
Walh Hara posted:This is all interesting to me. Next year I'll partly take over a project of 3500 man days (core team 12 people). Currently, they're using bitbucket and jenkins for git/CI and excel for Sprint planning, organisation and backlog stuff. Obviously, I don't want to use excel, but am unsure what the best alternative is. You might as well stay in the Atlassian ecosystem if there's already an investment and you're not looking to change any of the other parts of the stack.
|
|
#
?
Nov 11, 2019 19:25
|
|
|
Actually, the weird thing about the Atlassian ecosystem is that Atlassian products don't generally interoperate with each other especially well. Pretty much all of their products are independent acquisitions that were rebranded and then minimally integrated.
|
|
#
?
Nov 11, 2019 19:32
|
|
|
Yeah, we have some rather fragile webhook things to do stuff like change ticket state when PR states change. They've been broken for a while now because we renamed a ticket state 
|
|
#
?
Nov 11, 2019 19:48
|
|
|
Munkeymon posted:Yeah, we have some rather fragile webhook things to do stuff like change ticket state when PR states change. They've been broken for a while now because we renamed a ticket state I have no idea if that would solve your problems, but Jira has support for "Smart Commits", which let you transition issues via magic strings directly in commit messages: https://confluence.atlassian.com/fisheye/using-smart-commits-960155400.html It's...alright, I suppose?
|
|
#
?
Nov 11, 2019 20:23
|
|
|
A bone stock jira is pretty alright. People go crazy with customizations and make it terrible. If it's on-prem they under resource the infrastructure and everything crawls. The problem is almost never the tool and the tool will almost never solve the problem.
|
|
#
?
Nov 11, 2019 20:32
|
|
|
Inacio posted:Well, the worst possible thing that could happen has happened: I've lost access to my GitHub account. Is your clock up to date on your machine? I once had 2FA codes stop working because the laptop I got them from had gotten a full minute off. The site was fairly strict with their timings, so the codes were too early or too late to work (I forget which). Once I fixed time syncing they were good again.
|
|
#
?
Nov 11, 2019 20:35
|
|
|
Munkeymon posted:Brave of them to be so open about their mental illness
|
|
#
?
Nov 11, 2019 20:46
|
|
|
Progressive JPEG posted:Is your clock up to date on your machine? I once had 2FA codes stop working because the laptop I got them from had gotten a full minute off. The site was fairly strict with their timings, so the codes were too early or too late to work (I forget which). Once I fixed time syncing they were good again. I did go around the world during my vacation, but I tried syncing my time (an option on Google Authenticator) but no luck. GitHub support has replied and I could use my SSH key as proof it's really me, just waiting on them now.
|
|
#
?
Nov 11, 2019 20:47
|
|
|
Walh Hara posted:jenkins for git/CI and excel for Sprint planning, organisation and backlog stuff. While fixing things I’d recommend getting off Jenkins while you’re at it. Doesn’t have to be all at once but at least set up an alternative system and start moving the early adopters over. People may already have a preference for what they’d like. Everywhere I’ve seen or heard of Jenkins being used, it’s involved lots of time spent just fixing Jenkins when it regularly shits itself. At the current place we’re still on it and this is the case here too. We’re very diligent about using Jenkinsfiles for everything, rather then inputting everything by hand into a UI as is standard with Jenkins, so we aren’t at risk of losing a bunch of hand edited UI build configuration when it does fall over. But it’s seriously in net time sink territory at this point with how much poking and babysitting it requires. Fun Jenkins facts: - It was originally built to be a tool that you’d run locally on your machine to define useful jobs, like a worse and more complicated cron. All the networking and “machine” support was hacked in later as an afterthought. - The Jenkins method for telling a machine to do something is to create a Java object that when executed will run the command. This object is then serialized and sent to the target machine, which then deserializes the object and executes it. I call this “RPC by RCE” and it’s why the JVM version between the master and all machines must be identical.
|
|
#
?
Nov 11, 2019 20:59
|
|
|
i liked the jenkins bug in an old version that sometimes checked out files from svn and somehow duplicated the content of those files, leading to all kinds of entertaining and baffling build failures this bug was of course fixed in 2013. we were still running into it in 2018
|
|
#
?
Nov 11, 2019 21:08
|
|
|
Xguard86 posted:A bone stock jira is pretty alright. Every time we updated TFS at my old job it was a worry mostly because of our obnoxiously customized workflow not migrating correctly. So, I'm inclined to agree with this post. We did finally move away from on-prem source control to Azure DevOps, though, so that was nice.
|
|
#
?
Nov 11, 2019 22:12
|
|
|
e: wrong thread
|
|
#
?
Nov 11, 2019 22:17
|
|
|
Munkeymon posted:Brave of them to be so open about their mental illness JIRA is super attractive to bureaucrats who mistake busywork with productivity. At my current job this exists in the form of a QA department who refuse to learn any skills more technical than manually clicking our application and checking off a list. But look at all the JIRAs they're working on!!!
|
|
#
?
Nov 11, 2019 23:16
|
|
|
JIRA is an ideal way to practice SCRUM in an AGILE environment
|
|
#
?
Nov 11, 2019 23:19
|
|
|
Thanks! To be honest, I'm still unsure whether to use Jira. Is there any resource about it that I can trust (i.e. is not just marketing material)? Something about when it's actually worth using it. On the one hand I'm worried my current way of working won't scale to a project much bigger than any I've worked on so far, on the other hand I don't know what the benefit could be for me and don't trust the marketing material (nor my colleagues who promote it). Regarding Jenkins: yes I know, but sadly not something I can change. We have a whole separate team dedicated to supporting atlassian products in our company.
|
|
#
?
Nov 11, 2019 23:34
|
|
|
^^^ eh. Jira works as well as any “enterprise agile software” when it starts to scale. I’ve never used one that was great.
|
|
#
?
Nov 12, 2019 00:08
|
|
|
A lot of tools like Jira et al are used in areas where the current agile processes are already failing or a company that is decidedly not agile wants to pretend to be agile. So long as it is used correctly it's mostly fine, it's just that the marketing gobbeldygook often hooks the same idiot managers who have mucked up the process in the first place. It's better than nothing, but that could be likened to saying that using a belt sander to file your nails is better than nothing.
|
|
#
?
Nov 12, 2019 00:26
|
|
|
Jira is the Jenkins of Agile management software. Everyone uses it because it's what they've always used and when trying to use anything else so much bikeshedding happens in most companies they wind up back in the same spot once again.
|
|
#
?
Nov 12, 2019 03:58
|
|
|
Jira’s mature and enterprisey enough that its warts induce eyerolling instead of incredulity or rage. It’s Generally Fine.
|
|
#
?
Nov 12, 2019 04:24
|
|
|
rt4 posted:JIRA is an ideal way to practice SCRUM in an AGILE environment i'll have you know that jira also supports kanban and scrumban
|
|
#
?
Nov 12, 2019 04:25
|
|
|
raminasi posted:Jira’s mature and enterprisey enough that its warts induce eyerolling instead of incredulity or rage. It’s Generally Fine. At a previous large enterprise job, the BAs had filled the Jira board with so many queries stacked on queries that it crawled and suffered loading anything at all. Eventually this was discovered and fixed but it had to have been months of terrible performance just to view your equally terrible tasks.
|
|
#
?
Nov 12, 2019 05:09
|
|
|
rjmccall posted:Actually, the weird thing about the Atlassian ecosystem is that Atlassian products don't generally interoperate with each other especially well. Pretty much all of their products are independent acquisitions that were rebranded and then minimally integrated. 
|
|
#
?
Nov 12, 2019 15:07
|
|
|
qsvui posted:i'll have you know that jira also supports kanban and scrumban Of course, KANBAN is also supported
|
|
#
?
Nov 12, 2019 15:19
|
|
|
rjmccall posted:It's a good way to get incremental feedback from people. I wish this actually worked. I've tried so many times to tell people to review my work in progress stuff only to get ignored every time. Of course actually getting people to review your code at all is a struggle.
|
|
#
?
Nov 12, 2019 21:26
|
|
|
netcat posted:I wish this actually worked. I've tried so many times to tell people to review my work in progress stuff only to get ignored every time. Of course actually getting people to review your code at all is a struggle. We dedicate a portion of our morning standup to dole out pending merge requests waiting for review/approval. It's not perfect and it can still sometimes take 24 hours to get someone to look at something, but it improved drastically from what it was before.
|
|
#
?
Nov 12, 2019 22:11
|
|
|
netcat posted:I wish this actually worked. I've tried so many times to tell people to review my work in progress stuff only to get ignored every time. Of course actually getting people to review your code at all is a struggle. This was one of the many banes of my existence at my old job - I would put up a WIP and invite everyone to comment on it and review progress so it wasn’t a huge chore to review all at once at the end, but nope. And then after you finished and submitted your poo poo on time and everyone else failed to review it before the end of the sprint, the failure was still on you. At my new job, we’re pretty good at reviewing in a timely fashion - tasks are divided into much smaller chunks and are easy and fast to review.
|
|
#
?
Nov 12, 2019 23:34
|
|
|
Ice Fist posted:We dedicate a portion of our morning standup to dole out pending merge requests waiting for review/approval. It's not perfect and it can still sometimes take 24 hours to get someone to look at something, but it improved drastically from what it was before. there's this really good slack thing that pesters people until they review PRs. it's great and has really changed how PRs are done in our org.
|
|
#
?
Nov 12, 2019 23:51
|
|
|
If no one reviews it then it doesn’t go in by the end of the sprint and it is not my fault. I am not my coworkers’ keeper, do your drat job. I’m one of the only people that reviews PRs on my team.
|
|
#
?
Nov 13, 2019 01:52
|
|
|
How does that work? Do you mean others on your team just rubber stamp LGTM on the PR and send it through?
|
|
#
?
Nov 13, 2019 04:01
|
|
|
Not literally, just that work can stall for a good 4-5 days to be approved and deployed if nobody gets around to reviewing it without being explicitly asked to do so.
|
|
#
?
Nov 13, 2019 04:10
|
|
|
I’d always hesitate reading this one developers PRs because they were always changes to dozens of files and had thousands of SLOC changes. But I learned I often had to because they’d leave debug poo poo or just hundreds of lines of commented code in the change. Not sure if they’re still employed but I called it out as tactfully as I could when I left that job.
|
|
#
?
Nov 13, 2019 04:13
|
|
|
This happens even for one-liners.
|
|
#
?
Nov 13, 2019 05:59
|
|
|
I think I'm going to just allow 'push direct to master' for a while, so that people maybe stop feeling like they can do poo poo work and let someone else worry about the quality. Because as it stands right now, its either aggressive rubberstamping: +3000/-30 PR? Approved 10 minutes after creation! Or its the worst kind of limp PR: checking out the branch. Building it. And then just requesting changes for anything ReSharper comments on that hasn't already been done. Along with it still being an 11th hour process. What's that? Code freeze on Monday afternoon for the next release? *three PR's pop up right before lunch, with comment in teamchat "CODE REVIEW PLZ, URGENT, THIS IS FOR NEXT RELEASE" So that anything meaty that *does* get requested turns into //TODO: comments for the next generation to handle.
|
|
#
?
Nov 13, 2019 07:24
|
|
|
I implemented two things that you should probably do: No code pushes 48 hours before release All merge requests must only do one thing only. Those two things really cleaned up merge requests.
|
|
#
?
Nov 13, 2019 07:27
|
|
|
My goto PR comments: "Please do not check in commented out code." on the files and then request changes with "Please clean up files before submitting a PR. I will look at the functionality after it is cleaned up." Another one would indeed be: "This change is out of scope for the PR and the story you reference, please create a separate PR for this." And simply return it marked "request changes". Third: "You change the functionality of the public API of the class/system, but not change any tests. This means that either the tests were not properly covering the code to begin with or you add functionality without adding any tests. In either case, please add tests on the unit/system/integration level to cover your functionality." Short term people complained a lot, after a few months the PRs were clean and single topic and thus understandable. Code quality improved a ton as well. I work as a contractor and these three get used in every new project I join.
|
|
#
?
Nov 13, 2019 07:54
|
|
|
netcat posted:Of course actually getting people to review your code at all is a struggle.
|
|
#
?
Nov 13, 2019 08:39
|
|
|
In my experience what happens is a mix of two things, One is its possible for a couple people to kinda duck having to do PRs, focusing on their own work, and the rest of the team just ends up picking up the slack. The other is a sort of bystander effect where everybody is busy and everybody thinks "well, I've gotta get this done, somebody else will surely take care of this pr!" and as a result nobody does, and you reach pr gridlock. We've implemented a standard template for PRs where you have to fill out certain steps as part of the git request message, it saves a lot of headaches and reminds the person who wrote it to check the original ticket and makes sure everything's cleaned up. ratbert90 posted:No code pushes 48 hours before release Embrace CICD 
|
|
#
?
Nov 13, 2019 09:05
|
|
|
We assign our PRs to people who either made the ticket (if it's made by an engineer), someone with direct knowledge of the features in question, or just the engineers who have been around forever. Most people who do these reviews are extremely sketchy on when they'll get them done.
|
|
#
?
Nov 13, 2019 13:55
|
|
|
|
| # ? May 26, 2024 16:56 |
|
|
Keetron posted:My goto PR comments: That is a very nice ruleset and I'll steal that when next I have problematic PRs.
|
|
#
?
Nov 13, 2019 14:57
|
|