Techniques for sharing limited resources in a partially remote environment?
-
So we have, for various reasons, a limited pool of persistent development environments for one of our products. Basically, we have 6 "nyota dev environments", each of which can only be used for one thing at a time. Each one must be attached to a development sandbox before either side can really do the workflows for this product; the sandboxes are on a per-ticket basis. The dev environments have some particularly tricky infrastructure needs, which make them unsuitable for being ephemeral like the sandboxes.
So with 3 devs and 6 environments, we need some way of "locking" a resource. If we were in person, we could do it with physical objects--you check out a "dev environment marker" and put it back when you're done with it. But when hybrid (in office 2 days a week, remote otherwise), that becomes more of an issue. And the attach process is destructive, wiping out whatever state was there and requiring some real gymnastics to get things working again.
I guess we could have a shared document, but that's one more thing to update each time. Or we could allocate the environments per dev and you have to ask if you need one outside your 2 allocated ones. That's what we've been doing up to now, but it's annoying and certainly won't scale if the team gets any bigger.
Our ticketing process is Jira, and almost every ticket we do requires one of these dev environments.
Anyone got any thoughts on ways to coordinate these limited resources and signal "ok, dev-N is free"?
-
You said attaching is destructive, so there's some sort of attach/detach process. Can you wedge something in there? A log file for each one might be enough. ("Bob attached to Dev-3." "Dev-3 released.")
-
@Parody said in Techniques for sharing limited resources in a partially remote environment?:
You said attaching is destructive, so there's some sort of attach/detach process. Can you wedge something in there? A log file for each one might be enough. ("Bob attached to Dev-3." "Dev-3 released.")
Two things--
- The attach script (for various WTF reasons) runs on local developer machines. It calls a shared Jenkins instance to actually perform about 90% of the work, but that's annoying to go back and check.
- There is no release process, you just attach it to something else (resetting the state to default).
I'd like more of a way to have a dashboard so i can look and see "oh, dev-3 is free right now". I'm sure I could engineer something, but...meh.
-
@Benjamin-Hall Why not a simple Teams group where, when someone attach to a device, it writes it in the group chat, and also write in it when he's done with it.
I know, you have to rely on people to actually do it and not just
-
@Benjamin-Hall said in Techniques for sharing limited resources in a partially remote environment?:
It calls a shared Jenkins instance to actually perform about 90% of the work
So, what defines the "is attached" state? Is it like a network connection or something?
If so, simply monitoring the connection state of that port (or whatever) and a flag tracker (for who the dev was last attached would be updated) should be sufficient to create that dashboard.Alternatively, since you mentioned it was Jenkins, it should be possible to put a job step that watches said "is attached" state and stalls the job for that jenkins slave and thus takes it out of the pool for selecting a host to attach (assuming given configurations and plugins).
If it's just a job call and the environment can be used indefinitely without any indicator that it's in use, I suppose something would need to be done to have such an indicator before anything can be done with reliability.
-
@Benjamin-Hall said in Techniques for sharing limited resources in a partially remote environment?:
So with 3 devs and 6 environments, we need some way of "locking" a resource. If we were in person, we could do it with physical objects
[...]
I guess we could have a shared document, but that's one more thing to update each time.Since you're saying there is no "release" process, that means no special action happens when a resource becomes free (again), so I don't think you can find a solution that wouldn't be "one more thing to update" (the "release" event has to be manually triggered, basically). I guess avoiding a manual "lock" event would be nice (i.e. just have a "release" one) but actually it might be easier for humans to remember doing it if there is a nice symmetry (lock/release) rather than just one of them.
Anyway, one idea trying to mimic a "physical object," though I don't know whether it actually works:
Use some shared folder (one per machine, or a single one with one file per machine?). When "locking" a machine, a dev opens the corresponding folder/file. This locks the folder/file and prevents anyone else from accessing it, until it is closed (=released).
I don't think this works with e.g. simple text files in a folder (I think you can have several people reading them at the same time?), but this might be feasible with folders themselves since IIRC there is a feature to limit the number of concurrent users, see e.g. this SU post.
(of course that assumes you can all access a shared Windows drive i.e. that everyone uses Windows, or that something similar works with other network sharing protocols...)
-
@Benjamin-Hall said in Techniques for sharing limited resources in a partially remote environment?:
If we were in person, we could do it with physical objects--you check out a "dev environment marker" and put it back when you're done with it.
It's called "shingle" https://thedailywtf.com/articles/The-Source-Control-Shingle
