Add recipe for branch-based secrets management

[Clemens Wolff (c-w)]

This pull request adds a section about branch-based secrets management to the engineering playbook. The section is based on findings from a customer project and answers questions such as:

• Why do we need branch-based secrets management?
• How can we implement branch-based secrets management?

The section is included as part of the continuous deployment heading since it already has some prior content around secrets management.

[Federica Nocera (fnocera)]

This is great!

[Federica Nocera (fnocera)]

Sara Spalding (@SaraSp) Beat Schwegler (@cloudbeatsch) flagging for review, thanks!

[Beat Schwegler (cloudbeatsch)]

lgtm

[Charles Zipp (charleszipp)]

I would invite Kevin Hartman (@kevinhartman) to take a look at the secrets part with node. We recently opened a story in our current project because in ACI, env vars are visible in the portal (thats how i understood what Kevin Hartman (@kevinhartman) and narmatha reporting). So is the env the best place to put secrets? Is there a different place for node containers that we should place secrets?

[Federica Nocera (fnocera)]

Charles Zipp (@charleszipp) I will message Kevin Hartman (@kevinhartman) to add a recipe for node secrets!

[Clemens Wolff (c-w)]

Charles Zipp (@charleszipp) The recommendation for using dotenv in Node came from Toby Bradshaw (@tobecodex) so perhaps he can add more context.

Personally, I like the way the section on Enhanced-Security Applications puts it: using environment variables is fine for most applications unless you have specific additional security requirements (in which case you'd likely have a security review, pentesting, etc. all set up which will inform the best enhanced security strategy for your use-case).

[Federica Nocera (fnocera)]

This looks good to me. This is something we can build on and add recipes for different languages etc.