Not open to public contributions about uno HOT 5 CLOSED

from uno.

Jacob,

hmmm....... Would everyone in the class need access to that private repository for local development? Or is only used on a production deploy?

from uno.

from uno.

Gotcha, that makes sense.

To clarify my thoughts then.

1. I also think creating the abstraction layer on the database makes sense :)
2. I think adding a private repository as a submodule makes sense to me overall.
3. It sounds like this is NOT the case, but if we are in a scenario where the entire class would needed to be added to the private sub-module repository, my counter thought would be.... could we just make this repository private? or delete/recreate this repository and make it private? I suppose I approach it from the thought of "does this just bubbling up the concern".
4. Most of the time that I've faced these problems at work, we've typically established a secrets management process, through one of the following:
   • A secrets mangaement tool (vault, AWS secrets manager, etc)
   • A private, yet shared file store (mounted directory, nexus, S3 Bucket)
   • A secure way of distribution....... (USB, encrypted emails, git submodules)
   • Managed entirely on the build/deploy process (jenkins, chef, salt, etc...)

The major problem with all of these solutions... is that short of sending an encrypted email.... it basically just bubbles up a credential issue. You have to pass someone credentials in order for them to get access to credentials....

So in your case, I think the most lightweight solutions are to either make the private git submodule... or to just make this repository private and store it here. I would lean towards the git submodule, as it could be entirely managed by the deployment/build process (Jenkins, Google Cloud Build), and you could limit access to the submodule.

from uno.

We are going to go ahead and add everyone as collaborators. This should work.

from uno.