-
Notifications
You must be signed in to change notification settings - Fork 43
Features
This describes both advantages and limitations of DropkicK (DK). You should understand both its strengths and weaknesses to understand if DK is something you can use in your organization.
You can describe your deployment in an almost natural language. You talk about what you want to happen without knowing physically where it may be happpening. In this sense, DK is almost declarative.
It's really nice when you can hand the deployment plan to your network admins and they can actually read what it is going to do. Then they can give you feedback about what you need to correct and what is good to go!
You explain in a code deployment plan what you want to happen on a deployment of a role. You put the actual where information in settings files that are targeted to a particular environment. Since these settings files are just javascript, they can be adjusted at run time if necessary.
You can just download the bits of DropkicK and start using it. No installation necessary.
It costs you nothing to use, the license is developer friendly (Apache 2.0). So you can use it with confidence at your place of business without worry that you haven't met some agreement.
Find a bug? Fix it and submit a patch. Or let us know on the issues list. You want to discuss something about dk? Drop us a line on the mailing list
Because DK can do remote execution at will, there is nothing that needs to be installed on the servers you are deploying to. This is good because it allows you to change your targets on a whim and there is nothing more to do than change your settings.
In some environments you have a lock down of who can do what. The deploying agent (the person running the deployment) must be an administrator of any machine being deployed to, and a system administrator on a SQL box for deployments.
Because DK provides you the ability to just deploy certain roles, you can separate roles into different batches that different network admins run. This allows you to be able to meet the needs of your organization and have a nice fluent deploy.
Servers that you deploy to must have WMI enabled. This is due to many of the tasks that DK uses to bring about a deployment are done through some WMI call or through WMI remote execution.
DK needs to be able to get to servers from where it is being deployed to. The deployment agent needs to be able to reach everything it deploys to.
Some folks will FTP the deployment bits to the server it needs to execute against and then log into it and run DK from there. This is a good way to get around this limitation, especially if say your PROD/DR environments are remote and everything else is local.
To successfully use DK, you must know where you are going when you build the code. You can technically get around this because the settings files are written in javascript, so you can edit them just prior to deployment if necessary. But it's better to know well ahead of schedule.