Me: So we're deploying this today on prod.

Junior: Can you record the deployment steps for us so that we can deploy whenever you're unavailable?

Me: Seriously?

I liked their enthusiasm though.

Maybe it's just too early as these chaps don't even know the basic commands right now.

What y'all have on this?

I mean it shows that they are looking for edge cases that might come up.

If you don't have your production checklist or steps documented anywhere and are gate keeping it by mental memory only, expect bottlenecks to arise. Granted I would still put a permissions check in place so only experienced people can do it if there isn't a dedicated team to do it and it can be toggled when needed.

A lot of fresh juniors probably have little to no experience with deployment of apps. Hell even my own alma matter has Databases as an elective and not a requirement to graduate still, but formal languages and automata is required to graduate.

i totally understand junior.
it is 2021 with ci cd, iac and all that shit. if deployment must be done manually it should be documented.

@TestInProd423 I understand the need to document the deployment but letting them do it is surely not a solution if someone experienced is unavailable.

Apart from those steps there are times when we gotta go through logs to know why something isn't working as intended.

We still have to take decisions to rollback incase something breaks.

Memory management and other OS concepts are surely a prerequisite but there's much more than it.

... You haven't scripted your deployment? I write a cli for everything coz I'm too lazy to remember anything...

A newbie alone should not be able to trigger a deploy. Most workflows involve code reviews and/or a permissions check on deploy, unless the entire team is experienced enough to skip that because pretty much everyone who has the code is also qualified for prod access.

@atheist We have ansible script which we trigger manually right now.

There are few issues which needs to be sorted out first to make it auto deployable by CI/CD pipelines.

@lbfalvy By steps, he also meant the password and the ssh keys to be shared too.

For the docs though, we surely have to create one soon.

Deployment should of cause be documented, but unless its completely automated I would require anyone doing it having been along a few times doing it under supervision.

But the best is if you can get it fully automatic.

It can take some time if you do not set it up from the start but its doable even with an old project.

@techcatchers I am currently writing ansible, with a python cli wrapper to run the right playbooks with the right variables, switching stuff for dev/prod (and one option to just "set up everything in prod"). The cli includes documentation of what each option does. There are some steps to set up the inventory, but other than that it's fairly self documenting.

Yeah, passwords/ssh keys should be kept reasonably secure tho.

@techcatchers

While you cannot record everything, I would certainly give a praise to the junior.

At least he _tries_ to be interested in the topics at hand.

Which is better than having to pull the intern by the ear to get him to listen and maybe not only look at the task at hand but at a broader picture.

Sure, they can't do the deployment and sensitive stuff like SSH keys and passwords should be omitted....

But the intern just turned himself into a viable suspect for reviewing docs and getting to know a lot of different aspects of knowledge, which you can later build up on (plus you get to know his knowledge).

Seems like a large win win for me.

The seriously is the thing I find... Rather shitty. Yes it's complex, without a doubt.

But a "It's a complex task, but I'll try to work out at least a full documentation - you won't do it in the near future on your own, but you can learn a lot I think" is a far better response.

Don't demotivate even if it means you'll have to work a bit more.

@IntrusionCM The seriously thing wasn't said to him directly though.

My bad, I should have put that in the asterisks.

I want all my devs to be independent enough to perform all the tasks that I perform someday but that doesn't mean now.

For this, while WFH I am available for them on meet during the working hours at all times and they can join anytime and ask for any doubts or queries they have. This reduces a friction by a lot during WFH and gets our work done faster.

More often then not, these guys even stay on call even when someone else is asking questions just to get a better understanding on those topics too.

The demotivation part doesn't exist at all here.

@techcatchers Happy to hear that. :)

Really glad that you take the time to help them.

It's sad that too many people don't do it.

Thank you for your work and answer!

🍪