|
Clanpot Shake posted:One weird trick to ensure your build fails for inscrutable reasons years after you leave the company, employers and devs hate it!  "Guys, I deleted a file named _canary and now builds are failing with an error that says 'canary hash mismatch.' How will we ever discover the cause?!??!"
|
#
?
Apr 19, 2017 20:31
|
|
|
|
| # ? May 9, 2024 21:26 |
|
|
revmoo posted:
You are vastly overestimating people's intelligence.
|
|
#
?
Apr 19, 2017 20:40
|
|
|
revmoo posted:
But what's the purpose of that? Just curious, never thought of having such a check in place.
|
|
#
?
Apr 19, 2017 20:45
|
|
|
revmoo posted:put my entire CI process into shell scripts, depending on Jenkins for just Git, credentials, and artifact generation, and nothing else. A nice bonus is that you can switch CI platforms in an afternoon since all of the build logic lives outside of it. This is the correct solution, as much as possible. Let CI tools do what CI tools are good at: scheduling builds. Another bonus is that it's easier to debug builds locally. revmoo posted:Also, protip; generate a 1mb file, commit it to Git, and then put the md5 of it in your deploy script as a canary. Abort deploys if the hash ever fails to match. I'm trying to figure out what the point of this would be.
|
|
#
?
Apr 19, 2017 20:49
|
|
|
Protip: have your deploy script check the company directory for your name, and abort if it's missing.
|
|
#
?
Apr 19, 2017 20:58
|
|
|
lifg posted:Protip: have your deploy script check the company directory for your name, and abort if it's missing. I can see a reason to do that though. A nefarious reason, but a reason. With the canary though ... im missing something.
|
|
#
?
Apr 19, 2017 21:07
|
|
|
Biggest thing with Jenkins is use the 2.0 Pipeline build system with a Jenkinsfile that's checked in side-by-side with the code being built. I had a case of this horrible poo poo where we had Jenkins config in git, the app we were building in git, and the support scripts the entire company used in git. All 3 could float around and trying to recreate an old build was an exercise in futility.
|
|
#
?
Apr 19, 2017 21:12
|
|
|
My problem with a Jenkinsfile is you can't run it locally. So, if you want to modify it, you have to commit and push every little modification of trying something.
|
|
#
?
Apr 19, 2017 21:15
|
|
|
Axiem posted:My problem with a Jenkinsfile is you can't run it locally. So, if you want to modify it, you have to commit and push every little modification of trying something. We use docker for that
|
|
#
?
Apr 19, 2017 21:17
|
|
|
revmoo posted:Also, protip; generate a 1mb file, commit it to Git, and then put the md5 of it in your deploy script as a canary. Abort deploys if the hash ever fails to match. Why?
|
|
#
?
Apr 19, 2017 21:27
|
|
|
lifg posted:Protip: have your deploy script check the company directory for your name, and abort if it's missing. haha, I like this one.
|
|
#
?
Apr 19, 2017 21:30
|
|
|
revmoo posted:
Perhaps I should have been clearer. The error code, since you wrote it, would easily lead the reader to the cause of the failure. The inscrutable part is why such a check exists in the first place.
|
|
#
?
Apr 19, 2017 21:42
|
|
|
Clanpot Shake posted:Perhaps I should have been clearer. The error code, since you wrote it, would easily lead the reader to the cause of the failure. The inscrutable part is why such a check exists in the first place. Because there are millions of reasons why a deploy could proceed with a bad build. Having a file to sanity-check against is not dumb or malicious. Several of you are though.
|
|
#
?
Apr 19, 2017 21:49
|
|
|
revmoo posted:Because there are millions of reasons why a deploy could proceed with a bad build. Having a file to sanity-check against is not dumb or malicious. Several of you are though. I put sanity checks in every feature suite  its the only way to avoid an AWS skynet
|
|
#
?
Apr 19, 2017 21:50
|
|
|
Just use a non-poo poo CI server like TeamCity, a non-poo poo deployment tool like Octopus Deploy, and 1 or more staging environments, and you don't have to mess around with hand-spun integrity checks. Tell your companies to stop being cheap and pony up the $1000 for real tools.
|
|
#
?
Apr 19, 2017 22:15
|
|
|
revmoo posted:Because there are millions of reasons why a deploy could proceed with a bad build. Having a file to sanity-check against is not dumb or malicious. Several of you are though. what are you sanity checking for? how on earth does this ever fail for a reason that is a problem with your build and not just with your canary ritual?
|
|
#
?
Apr 19, 2017 22:14
|
|
|
Oh boy, another day of reverse engineering revmoo's particular use case because of cagey phrasing around a strange behavior wholly without context or justification! Is a "good build" put through any UAT or are we defending against full auto? Who cares, it's irrelevant!
|
|
#
?
Apr 19, 2017 22:43
|
|
|
An old woman is watching the news, and hears that a man is going to the wrong way down the highway. So she calls her husband. "Revmoo," she says, "I just heard on the news that there's a guy going the wrong way on the highway. Please be careful!" "One guy going the wrong way," Revmoo replies. "They're *all* going the wrong way!"
|
|
#
?
Apr 19, 2017 22:52
|
|
|
There's a funny bug with old versions of the Jenkins SVN plugin. If you have one particular checkout strategy selected, you would find that Jenkins occasionally duplicates the content of every file. So you'd have a file with public class Foo { ... }, followed immediately in the same file by another public class Foo { ... } definition. Luckily this causes immediate (but absolutely baffling) build failures. This was fixed in Jenkins 1.470 or so, in mid-2013. How do I know about such an old bug? Take a guess at how maintained our infrastructure is 
|
|
#
?
Apr 19, 2017 23:03
|
|
|
redleader posted:There's a funny bug with old versions of the Jenkins SVN plugin. If you have one particular checkout strategy selected, you would find that Jenkins occasionally duplicates the content of every file. So you'd have a file with public class Foo { ... }, followed immediately in the same file by another public class Foo { ... } definition. Luckily this causes immediate (but absolutely baffling) build failures. You should see the piece-of-work that is the Perforce plugin.
|
|
#
?
Apr 19, 2017 23:08
|
|
|
B-Nasty posted:Just use a non-poo poo CI server like TeamCity, a non-poo poo deployment tool like Octopus Deploy, and 1 or more staging environments, and you don't have to mess around with hand-spun integrity checks.
|
|
#
?
Apr 20, 2017 00:15
|
|
|
Vulture Culture posted:TeamCity is unusably slow beyond a certain number of build configurations and stored builds, and it sucks poo poo to automate, but it's otherwise a pretty good option for small teams building somewhat infrequently I never found that to be the case, but I always set up multiple build agents on separate boxes and put the server on a capable machine. I can't comment much on automation beyond triggering builds on commits to various branches, because I haven't seen the need. Jenkins is great for DevOps guys, because there's so little out-of-the-box functionality.
|
|
#
?
Apr 20, 2017 01:03
|
|
|
Hughlander posted:We use docker for that Just feels like overkill to me, though I can see the value depending on context. I just like sticking with my Makefiles and bash scripts.
|
|
#
?
Apr 20, 2017 02:27
|
|
|
Axiem posted:Just feels like overkill to me, though I can see the value depending on context. I just like sticking with my Makefiles and bash scripts. Problem there is if QA needs to make a build that by default has debug off but profiling on and targets qa4 for connections but staging for events. That's a big set of config passed to a script from parameters. And if you need to rebuild a branch from last month before the events were parameterized you need to handle the case where you are getting args that don't make sense.
|
|
#
?
Apr 20, 2017 03:46
|
|
|
lifg posted:An old woman is watching the news, and hears that a man is going to the wrong way down the highway. So she calls her husband. Also, I still don't understand the canary md5 thing but I desperately want to, in excruciating detail
|
|
#
?
Apr 20, 2017 04:08
|
|
|
Hughlander posted:Problem there is if QA needs to make a build that by default has debug off but profiling on and targets qa4 for connections but staging for events. We end up having a separate app we've developed internally to handle general configuration like "what servers are you pointing at". And debug/profiling are done based on which build you want (dev vs. prod, basically). At your level of complexity, I can see why you'd go the route you do, and can't fault you for it (though I'd still recommend that all Jenkins does is make it easy to specify the config values passed into the script). At smaller levels of projects, that sort of thing can be overkill. I still stand by "put all the build logic/commands in scripts/Makefiles called by your CI system" 
|
|
#
?
Apr 20, 2017 04:35
|
|
|
What does everyone value a point as for Agile? Our pointing system hinges on this. For example we decided that to an existing form, to add one value to save is 3 points. That's our baseline. That includes DB changes, Mapping changes for Hibernate, Java Beans and the actual "FormSave" class / method that is called. Then every place it is displayed. Has anyone else done anything similar? Has it skewed pointing, especially in the eyes of management?
|
|
#
?
Apr 20, 2017 04:57
|
|
|
No advice needed, just want to bitch. I'm not terribly skilled. Never went to school, wholly self taught, lucked into a development job. Been doing a shitload of reading to offset that. However, I find myself in the position of being the sole developer working on a multi-million dollar legacy software system. I'm basically the rear guard, during the deployment of v2.0, which has around 30 devs working on it. There are about three other people in the company that know this software, and I'm strongly discouraged from bothering them for advice, but I am literally the only person who duct tapes this codebase together for 99% of our paying customers. But hell, a paycheck comes in every two weeks, and most days, I don't even put on pants, so I can't bitch too much, but gently caress, I feel overwhelmed. Edit: If I'm gonna bitch, might as well get it all out. The outsourced QA team told me today they don't have time for my software, last time we did in-house QA, a stupid bug I wrote made it through to production, which cost me a weekend. I get stories that rely on dependencies that haven't even been written yet. And since I'm the SME on our only product that anyone is using, I spend a good chunk of my day walking our support department through their own jobs. Allegedly Allergic fucked around with this message at 05:24 on Apr 20, 2017 |
|
#
?
Apr 20, 2017 05:16
|
|
|
Allegedly Allergic posted:I'm strongly discouraged from bothering them for advice Jesus Christ. gently caress them. That's a major black flag if I ever saw one.
|
|
#
?
Apr 20, 2017 05:39
|
|
|
geeves posted:What does everyone value a point as for Agile? Points are arbitrary and indicate relative size. You've decided that 3 points represents something of that level of complexity. Something that's 6 points is more complex than that. Something that's 1 point is less complex than that. I've been preferring non-numeric sizing lately. T-shirt sizes work well. S, M, L, XL, XXL. Anything landing above L is broken down further. The thing that skews points in the eyes of management is when they try to assign an hour value. If someone says "it seems like 3 points is about 5 hours, so 1 point is equal to about 1.6 hours...", that's when the trouble starts. The next step from there is to say "Okay, so each developer can do 5 points per day, we have 2 week sprints and 3 developers, so that means we should be able to fit 150 points in the sprint!"
|
|
#
?
Apr 20, 2017 05:48
|
|
|
New Yorp New Yorp posted:The thing that skews points in the eyes of management is when they try to assign an hour value. If someone says "it seems like 3 points is about 5 hours, so 1 point is equal to about 1.6 hours...", that's when the trouble starts. The next step from there is to say "Okay, so each developer can do 5 points per day, we have 2 week sprints and 3 developers, so that means we should be able to fit 150 points in the sprint!" Everywhere I've worked has eventually devolved to this. I really want to try something like the t-shirt estimates you mentioned and see if it helps prevent it.
|
|
#
?
Apr 20, 2017 06:29
|
|
|
jony neuemonic posted:Everywhere I've worked has eventually devolved to this. I really want to try something like the t-shirt estimates you mentioned and see if it helps prevent it. "Each developer can do 2 S, 1 M, or 0.5 L stories in a day..."
|
|
#
?
Apr 20, 2017 07:16
|
|
|
Points eventually come to represent something real as the project continues and the team stabilizes. It's very important, however, that management be dissuaded by any means possible, for as long as possible, from reaching the incorrect conclusion that there can exist a mapping from points to time. That way lies Taylorism, perdition, and total project collapse. The reason managers, both middle and upper, are subject to this temptation is because their jobs are very closely tied to calendars, and they experience anxiety when they do not know when something is going to happen, like a baby who feels distressed and abandoned when their parent's face is hidden for a few seconds. I think what's harmful is the notion of sprints. By all means have a weekly or biweekly rhythm, and measure the team's velocity across no smaller unit of time than that, but don't formally plan ahead. You'll work on whatever's the highest priority among the things that are ready to be worked on (ideally visualize priority with a queue so it becomes clear that making something the top priority means making everything else lower-priority). Points must never become a commitment, only a retrospective measurement. Prevent the manager from being able to say "How can we increase velocity?" by instead giving them the opportunity to say "Why was velocity low?" - and then one of the roles of a PM is to be the person the manager comes to with that question, and to always have an answer for it. As often as possible, that answer should be one that gives the manager something to do other than micromanage the devs. That's the ideal, anyway.
|
|
#
?
Apr 20, 2017 07:30
|
|
|
We use Pivotal Tracker and it is designed to mostly work like that. Velocity is calculated each week, and the rolling average is used to very roughly schedule future stories into specific weeks, but our current week's work can change on a daily basis as the product owner reprioritizes. I don't know what this is properly called, to be honest. We call it a sprint but I don't think scrum methodology is supposed to change a sprint after it is planned. So maybe it's really just kan ban? (And yes, all this Agile terminology is wankery but calling stuff by the wrong name does make you look uninformed.)
|
|
#
?
Apr 20, 2017 13:00
|
|
|
As soon as you are measuring velocity for ANY reason other than sprint planning, your company is no longer doing Agile development.
|
|
#
?
Apr 20, 2017 13:19
|
|
|
smackfu posted:I don't know what this is properly called, to be honest. We call it a sprint but I don't think scrum methodology is supposed to change a sprint after it is planned. So maybe it's really just kan ban? Kanban is its own methodology, not just Scrum with less restrictions. You're probably just Doing Agile Wrong, like most companies. Under Kanban a developer has one (or maybe two or three) name-cards, and you can't assign work to a developer unless they have an empty name-card. If PM and QA are also using Kanban, they'd also have name-cards and you can't take a task out of your card until you're able to hand it off to a QA with an empty card. So the emphasis is on completing individual tasks rapidly and successfully at the expense of overall speed.
|
|
#
?
Apr 20, 2017 14:42
|
|
|
Mniot posted:Kanban is its own methodology, not just Scrum with less restrictions. You're probably just Doing Agile Wrong, like most companies. So if the QA queue is full, do I temporarily become QA, or just spin around in my chair until it frees up? Genuine question.
|
|
#
?
Apr 20, 2017 17:19
|
|
|
New Yorp New Yorp posted:Points are arbitrary and indicate relative size. You've decided that 3 points represents something of that level of complexity. Something that's 6 points is more complex than that. Something that's 1 point is less complex than that. I've been preferring non-numeric sizing lately. T-shirt sizes work well. S, M, L, XL, XXL. Anything landing above L is broken down further. If the team itself is functional and trying to be Agile that's actually a great thing. Just have them continue to estimate based on complexity. "Man this is really complex and that's 24 points for us." Then as their velocity goes up, the sizing remains the same, and the number of point-stories pulled per sprint is pinned to clock time, they wind up with more time to refactor and fix tech debt!
|
|
#
?
Apr 20, 2017 17:23
|
|
|
raminasi posted:So if the QA queue is full, do I temporarily become QA, or just spin around in my chair until it frees up? Genuine question. The goal is to get the work from start to finish. If there's a blockage anywhere you help unblock it. The idea is that value delayed is essential zero value. In your case this could mean helping test a story, it could mean joining someone elses' story that's in progress, but it's about moving things that are in progress to the done state. Think of it on the opposite end. Is the work "done" if QA hasn't looked at it and it's not released to customers? Are you going to keep pulling more stories or closing out a sprint and start a new one with this backup at QA? Is this something QA is capable of ever catching up or will they be getting further and further behind? What happens when they find a bug in a story you did last sprint but they're just now testing? How do you track that level of rework? One of our teams currently is working really well with a hybrid approach of Scrum + sprints, but each swimlane has an in progress limit. It leads to far more collaboration than the teams that don't do it.
|
|
#
?
Apr 20, 2017 17:27
|
|
|
|
| # ? May 9, 2024 21:26 |
|
|
Got a request today to put an urgent fix in for some URL validation that wouldn't allow us to specify relative URLs, only absolute ones with HTTPS. All morning, I've been scrambling to put the same fix in five different repos. Finally finished up, pushed them up to a PR and waited for them to build. Artifactory immediately ate poo poo and went down, and it's been down ever since. Tried to reach out to the person in charge of our Artifactory server. Was told he quit. No changes can be merged in or pushed out to production now. This is my life. 
|
|
#
?
Apr 20, 2017 17:42
|
|