-
Notifications
You must be signed in to change notification settings - Fork 43
Concepts
#Concepts of DropkicK
DropkicK (DK) has a few things that should be understood prior to using. It will greatly increase your ability to leverage DK to your wishes if you understand more about it.
The simplest concept of execution of deployment. This is a step that is involved with getting something set up during a deployment. This could be copying files or setting a folder permission.
This is a collection of one or more steps to do in making something happen during the deployment. Say a task is to copy some files. A step in that task might be to clean/clear folders. Another step is to remove read only attributes. The last step in that is to actually copy files/folders. This is nearly synonymous with the concept of deployment steps and often referred to that way, even by the maintainers of DK.
A role is a collection of tasks that as an atomic unit have set up a particular area of a deployment. Like a database. Or a Web site. A role contains one or more deployment tasks. See Roles.
This is a collection of all roles for making a deployment happen. This is what you write when you sit down to write a dropkick deployment for your code. See DeploymentPlan.
These are settings you can draw from in any deployment step. A core concept to DK is the idea of environments and is baked into all settings. See DeploymentSettings.
A deployment role is targeted against one or more servers. The deployment server is the physical server that a role is deploying to. These are the physical servers that you want to target Deployment Roles to for a particular environment. Each role you want to deploy will need at least one physical location. See ServerMaps.
When certain tasks must be run against the server they are targeting, DK will copy over an executable to a known location on that machine, run it through WMI on that particular machine, wait for it to finish, and then bring the execution log back to the main logs. This means you do not need a service installed on the remote machine for installation. See Run Remote Processes
DK has a few logs that it puts together during the deployment. The one you see in the console is a summary of what is happening. There is a run log that contains details of everything that is happening. There is also a db log, a security log, and a file change log. These logs can be passed to each party that cares about them after a deployment for auditing sake.