This feels pretty primitive, but you can write a startup script for each specific project e.g. say one called `project123` where when you run it from the terminal, it switches to your project directory, starts Docker, runs the local dev startup command, opens your IDE, pulls from Git, opens the GitHub page of issues assigned to you, open a browser pointing to your localhost server etc. and whatever common stuff you need to do each day.
Add some scripting at the start to close windows/programs that might be sticking around from other projects, and now you can switch between projects with a lot less friction.
I always try to automate this because you get situations where you e.g. want to quickly fix a typo in a project, run tests, and push a commit, but because you fumbled on some dev step you forgot to do, you burn 15 mins figuring out why the dev environment won't start.
Same. I have a tmux-sessionizer like script that when I open a new tmux session for a project will automatically build out all the standard windows and pane setup for the type of project it is. Start neovim or rider, the dev server/browser if it's hot reloadable, start a test daemon to rerun tests on uncommitted file changes, etc.
If it's something I'm going to need most of the time when I open that project type then I automate it from bash scripts using simple identifiers like whether a go.mod, package.json, *.sln, etc exist. If you want to get even fancier then you could make scripts specific to each repo with a fallback, or make it search the existing sessions and close out any competing ones that would use the same ports or images. It's one of those things that does truly save 30 seconds multiple times a day, with minimal setup time for new projects once you know how you always structure your dev environment.
Earlier this year I made this https://doocot.sh/ for securely sharing secrets between people.
It's written in Go with no dependencies (or database). My intention was for an AWS image or something companies could run inhouse air-gapped from the Internet. Something like $10/m or so.
Longer term secrets were something I was looking at too. Pretty easy to extend this, but encroaches on Vault products and I felt that a harder sell to CTOs.
I've worked in infra/systems dev for years, and this sort of thing was bread and butter stuff.
Maybe I'll resurect it as an active project. What sort of feature/tool would get you to stop using Discord/Slack/etc for secrets?
> What sort of feature/tool would get you to stop using Discord/Slack/etc for secrets?
An integrated solution for the whole environment. I pick a project, it opens the IDE, sets environment variables, fires up other services/infrastructure, lets me select secrets (that might be shared between projects), lets me share secrets (with other people)... Probably something like tilt, but simpler, integrated into an IDE, and with support for secrets.
A secrets extensions for my backend app would be quite easy though, I think. It's just re-implementing the cli tool.
From the IDE command palatte you could:
- Settings.backend_host = private Doocot backend || public backend
- Settings.username = (automatic)
- Settings.identity = (automatic) something like ssh key data
- Share.Individual = "select from list of identities on backend"
- Share.Group = "select from list of groups I am in"
- Share.Link = "store secret and return a valid one-time url for a non-dev"
- Read.SharedSecrets = "list secrets shared to me or my groups"
Then it'd just be some thought into the simplest way to setup and maintain groups.
You've piqued my interest in it again though, as it doesn't seem much extra work to do the above. Given the backend more or less does most of it already.
Although it's not the full environment integrated solution you're looking for, I think one step forward in terms of how we share secrets is still useful.
I’m ashamed to admit we have a discord channel for each project and we dump secrets there with access control to the channels based on who works on the project.
Nothing fancy. Direnv with mise can handle most environment differences. Direnv with 1password integration adds secrets. Infrastructure lives as code in the `infrastructure/` directory of the project. Nix manages all tooling and native library requirements.
This feels pretty primitive, but you can write a startup script for each specific project e.g. say one called `project123` where when you run it from the terminal, it switches to your project directory, starts Docker, runs the local dev startup command, opens your IDE, pulls from Git, opens the GitHub page of issues assigned to you, open a browser pointing to your localhost server etc. and whatever common stuff you need to do each day.
Add some scripting at the start to close windows/programs that might be sticking around from other projects, and now you can switch between projects with a lot less friction.
I always try to automate this because you get situations where you e.g. want to quickly fix a typo in a project, run tests, and push a commit, but because you fumbled on some dev step you forgot to do, you burn 15 mins figuring out why the dev environment won't start.
Same. I have a tmux-sessionizer like script that when I open a new tmux session for a project will automatically build out all the standard windows and pane setup for the type of project it is. Start neovim or rider, the dev server/browser if it's hot reloadable, start a test daemon to rerun tests on uncommitted file changes, etc.
If it's something I'm going to need most of the time when I open that project type then I automate it from bash scripts using simple identifiers like whether a go.mod, package.json, *.sln, etc exist. If you want to get even fancier then you could make scripts specific to each repo with a fallback, or make it search the existing sessions and close out any competing ones that would use the same ports or images. It's one of those things that does truly save 30 seconds multiple times a day, with minimal setup time for new projects once you know how you always structure your dev environment.
https://mise.jdx.dev/ and https://developer.1password.com/docs/cli/secrets-environment... + IaC tool of choice (terraform/ansible)
Earlier this year I made this https://doocot.sh/ for securely sharing secrets between people.
It's written in Go with no dependencies (or database). My intention was for an AWS image or something companies could run inhouse air-gapped from the Internet. Something like $10/m or so.
The cli is pretty easy to integrate with scripts: https://github.com/thisdougb/doocot
Longer term secrets were something I was looking at too. Pretty easy to extend this, but encroaches on Vault products and I felt that a harder sell to CTOs.
I've worked in infra/systems dev for years, and this sort of thing was bread and butter stuff.
Maybe I'll resurect it as an active project. What sort of feature/tool would get you to stop using Discord/Slack/etc for secrets?
> What sort of feature/tool would get you to stop using Discord/Slack/etc for secrets?
An integrated solution for the whole environment. I pick a project, it opens the IDE, sets environment variables, fires up other services/infrastructure, lets me select secrets (that might be shared between projects), lets me share secrets (with other people)... Probably something like tilt, but simpler, integrated into an IDE, and with support for secrets.
Yeah, that's a lot of work. And developers would probably expect it for free give most things like that are also free(1) :)
There's a VSCode extension for Hashi Vault: https://marketplace.visualstudio.com/items?itemName=owenfarr... for secrets management, but it's complicated because Vault is complicated.
A secrets extensions for my backend app would be quite easy though, I think. It's just re-implementing the cli tool.
From the IDE command palatte you could:
- Settings.backend_host = private Doocot backend || public backend
- Settings.username = (automatic)
- Settings.identity = (automatic) something like ssh key data
- Share.Individual = "select from list of identities on backend"
- Share.Group = "select from list of groups I am in"
- Share.Link = "store secret and return a valid one-time url for a non-dev"
- Read.SharedSecrets = "list secrets shared to me or my groups"
Then it'd just be some thought into the simplest way to setup and maintain groups.
You've piqued my interest in it again though, as it doesn't seem much extra work to do the above. Given the backend more or less does most of it already.
Although it's not the full environment integrated solution you're looking for, I think one step forward in terms of how we share secrets is still useful.
Thanks
(1) someone always pays
I’m ashamed to admit we have a discord channel for each project and we dump secrets there with access control to the channels based on who works on the project.
It’s peak startup opsec.
tbh, that's one reason I asked this question ;)
Nothing fancy. Direnv with mise can handle most environment differences. Direnv with 1password integration adds secrets. Infrastructure lives as code in the `infrastructure/` directory of the project. Nix manages all tooling and native library requirements.
managing infrastructure services
Immediately reminded me of this (which I am no where near clever enough to use):
https://www.youtube.com/watch?v=dljNabciEGg
https://flox.dev is pretty great