Versioning components & dynamics

[pieter.v...@lightspeedretail.com]

Hi all,

We've recently started using sparkleformation and we have a question about how to manage different versions of a component/dynamic.
Say there's a authentication component that defines a couple of aws resources.
And that component is used in multiple templates. Where each template represents a certain environment: dev1, dev2, testing, prod, ...

What would be the best approach to handle changes in the authentication component.
Say we add a piece of infrastructure to it and that change gradually needs to be rolled out from dev to test to production.
And at the same time there might be other changes that need to happen to the dev, test & production stacks.

I thought about adding a version number at the end of the component filenames.
But it looks a little dirty.

Any ideas?

Thanks in advance,
Pieter

[Michael Weinberg]

Hi Pieter,

I think the correct way to handle that would be to have those resources in a dynamic, not a component, first of all. The dynamic can accept configuration, passed as arguments in the template via a hash. To roll out your change gradually, you would adjust each template's arguments, in turn. Each change would represent a single commit/release/version (whatever your workflow is). Does that make sense?

[pieter.v...@lightspeedretail.com]

Hi Michael,

Makes sense indeed, so depending on the config passed by the template the dynamic would create the needed infrastructure.
We'll have to play around with it to see how well it works.

That brings up another question, is there some kind of (rspec) testing framework for sparkleformation? Where you could easily assert that certain things would (not) be created.
A bit like chefspec for chef or rspec-puppet for puppet.
Say I make changes to the dynamic and want to deploy them to a dev environment.
Then I'd like to run a quick unit test locally asserting that the change in the dynamic is working as expected using the config provided.
And it is not impacting stacks/templates of other environments.
A diff on the generated json would be easy to do, but I'm wondering if there's something more integrated.

Thanks in advance,
Pieter

[sean escriva]

Hi Pieter,

For in memory type spec based tests there currently isn't anything I'm aware of, but perhaps look at http://www.heavywater.io/blog/2016/05/04/sfn-callbacks-serverspec/ for an example of how callbacks can be combined with serverspec to at least run tests against what was actually created.

-sean

[Scott Briggs]

Pieter,

Personally, I think the best way to handle this situation is to break out the authentication component into a sparklepack gem which can then be versioned. Bundler supports having a Gemfile in subdirectories so, assuming you have dev, test and prod in separate directories, you could very easily roll out a version of the authentication component to whichever directory you wanted to. You could structure the directories however you want.

The other advantage of using gem versioning is that you wouldn't have to actually change any code in the templates, all you'd need to do is change the version in the Gemfile and update the stack. Much less room for error and much much less tedious than using a dynamic.

Cheers,

Scott

[pieter.v...@lightspeedretail.com]

Hi Scott,

That sounds like a nicer solution.
Do you happen to have a code example of such a setup somewhere?

Thanks in advance,
Pieter