Pre and Post Deploy hooks #98
Conversation
|
Thanks for the PR @itsjesseyo! I appreciate the contribution, have you taken a look at this by any chance? https://github.com/mvila/serverless-plugin-scripts I'm wondering if it would accomplish much of the same sort of thing? |
|
It does, but there are certainly usage implications. Users would have to make two other custom blocks, and make two additional command-line commands to trigger it. Additionally, it's another dependency for what is a very common task - npm run build. If it's not a standard feature in this plugin, then I personally would just run npm run build myself. it would amount to less work than using serverless-plugins-scripts. I suppose the core goal is just to run whatever build command you need for your framework. I could simplify it and reduce risk of bugs by storing common build commands and giving people a flag to trigger it. |
|
@itsjesseyo Really appreciate the work here. If we're thinking about a build process would this add something over adding your build commands to an I would see I'm hesitant to add another way to do it without understanding the use case better. If there's a use case I don't know of that isn't covered by easily adding commands in Let me know what you think, if we do go forward with this PR here's a few things to add:
|
|
That's fair, and it is the kind of thing that opens up room to get bug reports coming in for an end users bad usage. And it makes sense that you want to keep a minimal set of useful features in your plugin and not do things that 'feel extra'. I have a developer I'm working with now that would prefer a custom shell script for example over using finch at all and I get a similar sort of response from him about using this - i can do this in my own script, so why do it? I have definitely written scripts and chained things together in npm package files, but given that it's strings the readability is wretched, debugging difficult, handing it to a new person often confusing. That's made better by putting it into shell scripts of .js files. However, anywhere where logic can be turned into configuration is good I think, and having a single point of entry is good. I think serverless.yml is a good place for the triggering of build scripts. I think that the next very minor step in that logic is the array of processes that could to occur. I can quickly debug issues by commenting out one line at a time and see what changes. and it doesn't affect code. So that's why I trended to ward this line of thinking. As for what do you need besides a single build line, that's a good question too. Here's an example : Immediately I see the need to update the buildpoilcy resource name to match the name that's deployed for each stage. I currently use variables to deploy finch like "serverless client deploy --stage staging" which results in a bucket called "provider.name-staging". It seems a very common thing to need the bucketpoilicy to be updated due to the name dependency. Again, i can resort to another plugin/serverless trick, add the functionality to finch itself, or make an npm package and trigger it - which is what I expect I will need to do anticipating that you'd prefer this feature not be added to finch. Another example: we post slack messages for deploy processes both when they begin and end. Another example: Our VPN ip addresses are posted in a repo and updating the bucketpolicy to the latest version could be as easy a a pre build and deploy git pull. they do update periodically, and recently often due to everyone working from home. We're also thinking of making a tools that allow us to add external orgs to specific apps, and has variations for build stage, as production should be closed to everyone accept your cdn (say cloudfront or cloudflare depending). this can definitely be done in a shell script or something. I'm really thinking on the level of Ford manufacturing. I have new workers and contractors with various skillsets at skill levels, and I need to be able to handle a simple unified process that is taught easily and consistently. I can understand if it's not the direction you'd like your plugin to go. I definitely have the ability adjust my thinking and also make a plugin just for our org. I will definitely update the PR to have the requested changes. |
|
I really appreciate the detailed examples here. I think there's plenty of valid use cases in there but I'm still trying to understand why they are not already easily achieved with the current solutions. Take the buildpolicy example - I think that was in reference to bucket policies? But correct me here please. We currently have options to deploy stage based Posting slack messages for deploy processes also makes sense to me. I could see why that is useful, but that would seem to fit better in a CI/CD system like Framework Pro/Circle CI etc. - I think Framework Pro has these events already? VPN IP - So this is a single external file that you'd like to reference and pull the contents into your bucket policy somehow? This seems potentially like a build system step? It's an interesting use case here, but I'd expect you want to keep the actual policies in version control so I'd still refer to the version controlled JSON file that you update and then run another My main concern here is that adding another way to do something means supporting another way to do something. I'm selfish and lazy so I'd rather have less options to manage and maintain myself unless they provide a significant new functionality that can't already be achieved elsewhere. (Like #96 which I'm still working on, thanks for the PR there again!) |
|
Going to close this for now, but feel free to reopen if you have other discussion or disagree with the decision. |
Background
#97 pre and post build commands
Proposed changes
add before and after hooks to the deploy process and call commands passed in to the yml. I used exec for simplicity, but it has a disadvantage that the buffers can fill up.
Proposed reviewers (optional)
[@ mentions of other contributors]