Feedback thread for Deployment Hook feature

Question

We're planning a new feature to let you customize what happens during deployment when you git push to Azure. Here is the speclet

Please use this thread to discuss and give feedback. Thanks!

Answer 1

Instead of a batch file, how about Powershell? That way we could import psake and go to town.

Answer 2

I don't like the deploy.cmd.

I like organizing my codes into different folder docs/ src/

I would suggest a .kudu or .azure or .kuduconfig or .azureconfig.

And please don't make it xml like what most ms config files does :) Either use .gitconfig format or yaml (iisnode) or json (package.json) at root.

This allows you at do lots of customizations not just with pre-hooks. Anyways here is the sample settings file.

webapp:
    path: 'src/web'
    git:
        hooks:
            post-receive: hooks/postreceive.cmd
            post-update: hooks/postupdate.bash
    iis:
        netversion: 4.5
webapiapp:
    path: 'src/web.api'
    git:
        hooks:
            post-receive: hooks/postreceive.cmd
            post-update: hooks/postupdate.bash
    iis:
        netversion: 4.5
nodeapp:
    path: 'src/nodeapp'
    git:
        hooks:
            post-receive: hooks/postreceive4node.cmd
            post-update: hooks/postupdate4node.sh

it adds support for multiple apps that are in same repository too. also supports for multiple pre post hooks. for example, i may also want prehooks so if tests fails, it shouldn't deploy/swap. also allows to change certain iis settings like if i want to target particular .net version and so on.

And also I would love to have bash and those files available for hooks coz bash scripts are also quite powerful. (I just don't like powershell although for certain things it makes perfect sense.)

Also might also want to support importing incase the apps are sub-modules

webapp1:
    import: submodule/webapp1

Answer 3

That was my inclination at first, but you can always invoke PowerShell from the batch file; small one liner is all it takes. Starting from CMD gives the most flexibility to do whatever else you want IMHO.

Answer 4

That's correct, the batch file is a bootstrapper into your build system. You don't have to write complex logic in there directly.

@PrabirShrestha What you talk about sounds out of the scope of kudu. We're merely talking about replacing the default 'building and deploy' logic that happens today when you do a git push. There's no configuration necessary and it's a pure naming convention way to do whatever you want as part of the deployment process. 

Also, note that deploy.cmd isn't tied to azure. You can write the script in a way that it's runnable locally. The advantage there is that you can see what will get deployed when you push to azure.

Any subsequent, more granular features can be built on top of this extremely generic and flexible feature.

Answer 5

1) Same here, PowerShell preferred instead of / in addition to cmd file. You could look for either one. Powershell can be invoked from the command line, but the other way around works just as well; they are equivalent. Cmd is simply outdated as a standard for scripting.

Note that if you invoke powershell from a small custom powershell host (a fairly simple class) in your managed code, you can pass access to in-memory objects to the powershell script, so it can interact with those variables in powershell or even in inline C#. Much more powerful than environment vars.

2) Also, provide a way to invoke the standard deployment from the script file, so you can not only replace the standard deployment but also extend it with custom steps before or after the standard steps.

Answer 6

See Drew Marsh's commenton powershell:

That was my inclination at first, but you can always invoke PowerShell from the batch file; small one liner is all it takes. Starting from CMD gives the most flexibility to do whatever else you want IMHO.

2) The achieve this we plan to give out the default deployment script so that you can override small parts of it in your scenario. 

This feature isn't just for windows users either. People on OSX developing nodejs apps will also be able to write custom deployment scripts. We wanted to make it as flexible as possible without locking you into a specific technology or without recreating a custom build systems with lots of events.

Answer 7

As a follow up, note that we made a design change on this feature. Instead of Kudu looking for a specific file like deploy.cmd, this feature gets enabled by add the command to run to the .deployment file, e.g.

[config]
command = node build.js

This way, it's not tied to a specific command shell.