3 ms·

Shameless plug: I'm currently working on a service that'll spin up / tear down environments automatically for each branch in your repo. We're focusing on the ma

Shameless plug: I'm currently working on a service that'll spin up / tear down environments automatically for each branch in your repo. We're focusing on the manual testing use case between designers and front-end engineers, so prod deployment is omitted from our featureset. But if you're looking to spin up ephemeral environments without building something yourself, check us out: https://featurepeek.com https://featurepeek.com

org3432 8y ago
Great stuff, I like the idea of bringing the same level of reasoning that's been hard learned over the past 50 years of software development to devops too. Currently the state of devops tools includes omitting debuggers when a company makes a new DSL, poor if any linting, low to non-existent test coverage so obvious bugs and regressions are normal, very poor IDE integration if any, often no real way to test locally, and not surprisingly the tools are bug riddled and at best scratch a single itch in an eco system w/o directly addressing the overall business problem.
deleted 8y ago
[deleted]
danenania 8y ago
Our product EnvKey[1] can also help to secure and simplify configuration of ephemeral environments—all you do is set a single ENVKEY environment variable, include an envkey library, and then all the secrets/credentials/config you need will be made available and kept in sync on each load. You also get a nice ui for editing variables and managing access. Ah, and all this is done without trusting a central server through the magic of end-to-end encryption. I think it could potentially jive well with a tool like yours given that proper secrets management can be a tricky piece of this puzzle. 1 - https://www.envkey.com https://www.envkey.com
- andrethegiant 8y ago
  Stumbled upon this the other day! Will take a look
- dvtrn 8y ago
  This is really interesting. My team is currently solving the question of ephemeral env vars through a lot of wololo (for you Age of Empires players out there) in terraform and PUT-ing the results into a local consul cluster. Being able to instead write an env and have my application not particular care where it retrieves it from as long as a library is available is something I'm going to put in front of the rest of my team on Monday.
- koolba 8y ago
  The primary problem with ephemeral environments isn’t distributing secrets, it’s provisioning the environment itself. It’s perfectly fine to generate an empty, self contained, with dummy “abcd1234” passwords or randomly generated credentials that are used only locally.
  - danenania 8y ago
    That works for services you control, but if you depend on external services, and these are relevant to what you’re attempting to test with a tool like FeaturePeek, then you still need to deal with credentials. Or am I missing something?
aratno 8y ago
Currently my team uses Heroku review apps for this, and the experience has been excellent. Opening a PR for our frontend automatically opens a review app, which gets designer sign-off before code review.

org3432 8y ago

Great stuff, I like the idea of bringing the same level of reasoning that's been hard learned over the past 50 years of software development to devops too. Currently the state of devops tools includes omitting debuggers when a company makes a new DSL, poor if any linting, low to non-existent test coverage so obvious bugs and regressions are normal, very poor IDE integration if any, often no real way to test locally, and not surprisingly the tools are bug riddled and at best scratch a single itch in an eco system w/o directly addressing the overall business problem.

deleted 8y ago

[deleted]

danenania 8y ago

Our product EnvKey[1] can also help to secure and simplify configuration of ephemeral environments—all you do is set a single ENVKEY environment variable, include an envkey library, and then all the secrets/credentials/config you need will be made available and kept in sync on each load. You also get a nice ui for editing variables and managing access. Ah, and all this is done without trusting a central server through the magic of end-to-end encryption. I think it could potentially jive well with a tool like yours given that proper secrets management can be a tricky piece of this puzzle. 1 - https://www.envkey.com https://www.envkey.com

andrethegiant 8y ago
Stumbled upon this the other day! Will take a look
dvtrn 8y ago
This is really interesting. My team is currently solving the question of ephemeral env vars through a lot of wololo (for you Age of Empires players out there) in terraform and PUT-ing the results into a local consul cluster. Being able to instead write an env and have my application not particular care where it retrieves it from as long as a library is available is something I'm going to put in front of the rest of my team on Monday.
koolba 8y ago
The primary problem with ephemeral environments isn’t distributing secrets, it’s provisioning the environment itself. It’s perfectly fine to generate an empty, self contained, with dummy “abcd1234” passwords or randomly generated credentials that are used only locally.
- danenania 8y ago
  That works for services you control, but if you depend on external services, and these are relevant to what you’re attempting to test with a tool like FeaturePeek, then you still need to deal with credentials. Or am I missing something?

aratno 8y ago

Currently my team uses Heroku review apps for this, and the experience has been excellent. Opening a PR for our frontend automatically opens a review app, which gets designer sign-off before code review.