How to trigger deployments to Chef managed environments from Release Management 2013 with Update 3 RC

Pre-requisites for triggering Chef deployments using RM:

1. Target node must already be bootstrapped and registered with Chef server
2. Relevant cookbooks uploaded to Chef Server. Cookbook should have an attribute which maps to build drop location.
3. Recipes assigned to Node.

Deployment using Chef:

1.  As a first step you need to setup Release Management Server as Chef Workstation. Refer to Setting up Chef Environment.
   1. RM uses Knife tool to communicate with Chef. If Knife windows plugin is not yet installed, run the following command:
      • gem install knife-windows --no-ri --no-rdoc
      • gem install knife-reporting --no-ri --no-rdoc
        
        
2. Create a Standard Environment in RM which represents Chef managed environment. 
   
   
   
   
   
   
   
   
   For more details on ‘Standard Environment’ in RM, refer to blog link:

   How to setup environments for Agent-less deployments in Release Management 2013 with Update 3 RC

   
   
3. Register your Chef node(s) as Standard environment server(s) in RM. Provide the server name and DNS name along with port number of the node. These machines can be virtual or physical machines, Windows or Non-Windows 
   
   
   
   
   Note:
   

·       Server name should be same as node name registered with Chef Server.

·       Port should be same as registered with Chef Server. Use ssh port for Unix based systems and WinRM port for windows based systems.

4.     Create vNext component and provide the path to package using Build externally option. It can be http/ftp path as well. 



Note:

·       Component source path will be set as Node’s attribute value.

·       Node’s attribute used by cookbook(s) to get application package
 

5.     Create a Release Definition using the Release Path having Standard environments that you have just created and add the vNext Component to it.



6.     Drag the action “Deploy Using Chef” into designer and fill out the Configuration variables and trigger a new Release




Details of each of the parameters passed:

• NodeName: Name of the Chef Node where you want to deploy the application. The parameter passed should match the name of the Server linked in RM Standard environment.
• IsUnixNode: Specify type of the machine. In case of UNIX based machines this parameter is set to true.
• Username/Password: Credentials to connect to the node. This should be a user (sudo privileges) with ssh permission for UNIX based systems and an user with winrm permission(or local admin) for WINDOWS based systems
• Component Name: Name of the component to be deployed.
• Attribute Name: Name of the Chef node attribute which is used by cookbook(s) to get application package as explained earlier. Nested attributes are supported. The format of this name is:  [‘AttributeLevel1’][‘AttributeLevel2’]…
• KnifeInstallationPath: Absolute path to knife.bat file on Release Management Server
• ChefRepoPath: Chef repo directory path on RM server.

Note: The vNext release pipeline differs from the Deployment Agent-based release pipeline. The vNext release pipeline has the following feature differences:

• vNext Components and Servers are parameters to deployment actions. They can’t be dragged on to the deployment sequence editor as in a Deployer based release authoring experience.
• vNext Components are used to define path to package and are not associated with Deployment tools
• Extending the target stage, tags-based deployment, agent-less deployments to untrusted domain, custom tools and actions, WinRM deployments using proxy server and manual intervention in deployment sequence features are not supported yet.
• WinRM session time-outs has to be set manually on the target machines. For more details refer to Installation and Configuration for Windows Remote Management.
• Flow controls viz. ‘Rollback’ &‘Rollback Always’ are not supported within other flow controls for e.g. Not supported within a Sequence or Parallel controls. Deploy action failures will trigger all previous rollback blocks as well, it is recommended that Rollback scripts are idempotent.
• Stages in vNext release paths must be of either the Azure environment or the on-premises (standard) environment type. A given release path cannot have both kinds of environment.