|
Yeah, I did kind of make it a thing to deploy everything automatically.
I've got ARM templates, Azure CLI scripts, PowerShell, everything, but once I press that button I know I'll get a working environment.
Even the SQL database is automatically updated using EF Code First (we'll see how that works out) 
I'm having a progress report with the IT manager next week.
I hope to release an entire new environment right before his eyes.
This guy is used to old skool server and desktop deployments, the entire team comes in at weekends to make sure it works on Monday morning.
So this should make him very happy
|
|
|
|
|
You're a braver man than me. I'm not sure I would have dared make such changes 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
You have to break a few eggs to make an omelette
Also, this code is not yet in production and apart from another developer, who works a few hours a week on this project, I'm the only developer.
Basically, this was all mine and it was all new.
The reason it wasn't consistent in the first place was that I had to make a few things work rather quickly to impress the customer.
Now that I'm in I can make it beautiful (and rather now than later)
|
|
|
|
|
Phew that makes a lot more sense. Making those changes to a live system would scare the cr*p out of me 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I've done it before, in production environments.
Now that I'm using CI/CD with Azure and micro services I find that it's indeed a lot easier to drastically change certain parts of the system
Especially if it's necessary.
Just change it, test it, and if anything still happens on production it happens...
Of course I don't work on any critical systems, a bug is annoying at worst.
Programmers get scared to change anything, then make their changes so that it impacts existing functionality as little as possible.
Ultimately, decision making becomes about software rather than business.
We want x, but make it y because the software is to hard to change.
If the business wants x they should get x even if that means rewriting parts of the application.
Although such decisions are also often driven by money.
It's difficult, but I always try to own the code and not the other way around 
|
|
|
|
|
A few months ago a new consultant attempted to deploy a change she had made to a component to our dev environment.
She did that successfully.
However, all other components were deleted in the process.
Took about an hour of running various Jenkins jobs to get it back again.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
Wow 
That's either some impressive incompetency or your release pipelines are very weird
I once pushed a chance to production, at the request of a client.
I simply pushed the deploy button of that project's release pipeline (because all my changes worked locally and on test and on acceptance).
Turned out that the version that was currently on production wasn't a version that was in source control, some manual steps had to be done.
I did not have the privileges to enter the production server at all, let alone do those manual steps.
The version I released fixed my issue, but broke another part of the application completely, because some unfinished changes were sitting on the master branch since long before I got there.
To make things worse, this component had two release pipelines and I used the wrong one.
Even though they used VSTS, the version I had just overwritten was gone, so I couldn't put it back either.
This was at 07:00, the person who could fix this came in at 07:30 and it all had to be back up before opening time at 08:00.
Needless to say, no one was amused, and the release pipelines were from then on off limits for contractors.
Kind of defeats the whole purpose of having CI/CD in the first place
|
|
|
|
|
Sander Rossel wrote: That's either some impressive incompetency or your release pipelines are very weird
She'd found a long dormant (about 4 years) script and used that. Not really her fault, it certainly shouldn't have been sitting around where someone could run it, but I still don't understand how she managed to find it and think it would do what she wanted.
First time she deployed something to QA she managed to kill that environment with a bug, everything unresponsive about 10 minutes after she deployed.
I never did let her get near production.
Some men are born mediocre, some men achieve mediocrity, and some men have mediocrity thrust upon them.
|
|
|
|
|
That somehow reminded me of Deedee in Dexter's Lab[^].
Spoiler: The button almost always destroyed one thing or another
|
|
|
|
|
I have two different parsers in my project that work using different algorithms (each with advantages and disadvantages) but they share a common grammar format.
The trouble is, with one of them I cannot honor all the features in the grammar, but with the other one I can. Hence, not quite a "common" grammar format.
Now here's the thing:
I can either:
a) move all of the tree shaping features off the pull reader and onto the parse tree (much less efficient but would support all types of parsers)
b) keep the feature in the pull reader that supports it and to hell with the inconsistency with the grammar.
I keep wanting to avoid option B because it's ugly, but I don't like option A either because it's less efficient and doesn't support the feature at the reader level.
What should I do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Go down the pub, have a good couple of stiff drinks, and wait for inspiration. Or arrest, kebab, hangover - whichever comes first.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Rule one: don't do anything until your really truly absolutely sure.
Leave well enough alone.
And go down to the pub.
|
|
|
|
|
if it was well enough I would leave it alone.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
How many people have died so far?
|
|
|
|
|
does my inner child count?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
First, make sure it's really dead...
|
|
|
|
|
Do a Captain Kirk.
Adjust the parameters of the test. Redefine the "commonality" of the grammar format so they both work off the same set of grammar rules. Then just allow the one that does more to do more independently.
Tada! 
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
so basically, option be with extra steps.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Yarp!
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
honey the monster, codewitch wrote: What should I do?
Do it all in the colour coding:
0. Green is for go/safety, unless your market is Asian, in which case it means a boy.
1. Red is for danger and "HOT! Don't Touch!", unless your market is Asian, in which case it means "Let's PARTAY!"
In a nutshell:
Horses : Courses
Never mind what you think/prefer/want; What do your users need?
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
Either option fulfills the functional requirements. It's just *how*
I think I'm going to go with option A.
It's easier for me to implement, and more importantly it's easier for the users to use -sort of, there's a very minor wrinkle (small learning curve) but it replaces some worse wrinkles.
Also, there are certain tree shaping features i'd like to add that are only possible by doing tree shaping on the parse tree rather than the reader.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
You got me at:honey the monster, codewitch wrote: it's easier for the users to use
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
option C would be easier too, (both readers support tree shaping) but apparently I'm not smart enough to make that happen.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
|
Lift and separate it is then.
|
|
|
|
|
*sigh* i think so.
It's not the refactoring that bothers me. It's the capability downgrade on the LL(1) parser.
Oh well.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
