Support lambda aliases & versioning?

[petemounce]

Support lambda aliases & versioning?

[deepakjois]

Versioning has already been added in 2300aeb

It should be documented in the README.

[deepakjois]

Actually, it looks like there is a bug in the implementation. It does not publish a version if the gulp-awslambda is invoked like this

return gulp.src("index.js")
  .pipe(zip("index.zip"))
  .pipe(lambda("ProcessRequest", opts))

This is because the code logic is short-circuited if the first argument is a string.

[willyg302]

@deepakjois This has been addressed in the latest release (0.3.0). The problem with passing a string is that you cannot specify Publish: true, so I went instead with opts.publish = true for this case.

@petemounce I'll have to give some more thought on how to support aliases as well, since currently params are more or less passed directly through to the underlying API, and supporting aliases would require multiple API calls. If you have any suggestions on what your desired experience would be please let me know. Thanks!

[petemounce]

@willyg302 I would if possible want to be able to separate "deployment" (in my mind, creating or updating a function) from "release" (creating or updating an alias - eg, promote beta -> production). For me, I'd like to be able to

• push a lambda zip file to create the function, when it does not exist
• push a lambda zip file to create a new version of a function, when the function does exist
• separately, create an alias against a particular version of a function (or, $LATEST if no version is specified)
• separately, update an alias to point at a different (given) version of the function (or, $LATEST if no version is specified)

I have not quite wrapped my head around the scenarios that I think Lambda can now support, but I think that Lambda versions and aliases can be used to

• do blue/green deployments/releases at function granularity
• do A/B testing since API Gateway resources can, I think, be pointed through different Lambda aliases depending on API Gateway stage variables

With the gulp project's code-over-config best practice and narrow scope of what modules should be created for, I would think that this module should only handle the concern of uploading the function code and optionally mapping to a specific version. The aws-sdk should then be used in a subsequent callback to map the new function version to one or more aliases.

Alternatively maybe a new module should be created to be piped the result of the lambda function upload, but I think the gulp best practice would be to just code that into a task since it isn't really doing anything with the stream but just configuring a service.

Great work on this module btw, it has been a huge time saver for me!

[petemounce]

@keithchilders: so, you advocate a new plugin, gulp-awslambda-aliasing (or similar) for what I describe? Wouldn't that make it less convenient to work with, since now one has to know about and install 2 plugins, which may have inconsistent ways of dealing with configuration and so forth?

[justinmchase]

Can you guys give a brief example of how to do a publish a new version with the params and opts both being objects?

Also, I would like to prevent publishes over an existing version. Is that possible?

[SeanRoy]

I have a solution for this. Watch for my PR.