K2 Process Deployment Dependencies

There have been some recent questions to me about K2 process deployment dependencies. I wrote the chapter in the book which focused really on how to deploy a K2 process or SmartObject from one environment to another. It discussed the relationship between environments and the StringTable, MSBuild and deployment dependencies you need to consider. However there are some elements to a K2 process deployment that you still must consider which can be taken for granted.

Remember that most everything you configure in the K2 Workspace must be re-configured in your destination environment. Let me clarify this:

• K2 Roles – Roles within K2 are created on the K2 Workspace, they are not defined as part of the K2 process. The K2 process will reference them; and if they are not there, you will get a deployment error when deploying from one environment to another. There is a K2 blackmarket projects that can help with this - http://www.k2underground.com/k2/ProjectHome.aspx?ProjectID=57 and http://www.k2underground.com/k2/ProjectHome.aspx?ProjectID=107
  
• Environments – This is a tricky one to explain and recommend that you read the book. When doing a process K2 process, values in the destination Environment will set into the StringTable. So the K2 Development server will have values in the Environments and when a process is deployed to a K2 Production server the StringTable will be populated. However the K2 Production Server will not have values populated its Environment Settings in the K2 Workspace. Environment Settings are unique to the server. This can be a challenge if developers have localized development environments and they need to share kprx files. The developer will need to create the Environment settings for their localized environment.
  
• Working Hours – Will again need to be reconfigured in each environment manually as they are not part of the process definition; they are just referenced.
  
• Permission (Server and Process) – It is obvious that K2 server permissions will need to be reconfigured on each server. However remember that the Process permissions will again need to be re-configured on each sever the process is deployed to. It is not part of the process definition.
  
• Error Profiles – Those will need to be reconfigured on each K2 server. You may be creating profiles by process definition.
  
• SmartObject Services – This is discussed in the book but worth mentioning again. SmartObject Services like the SmartBox and AD are deployed in every K2 server as part of the install. However other custom SmartObject services are not and this can cause a wrinkle in your deployment. In the K2 book, there is a section devoted to GUID in a SmartObject (Pages 323 to 325). This is a must read. Here are some K2 blackmarket projects to help with this - http://www.k2underground.com/k2/ProjectHome.aspx?ProjectID=71 and http://www.k2underground.com/k2/ProjectHome.aspx?ProjectID=25
  

You still also need to consider all other applications and components that must be deployed before you deploy your K2 process. For instance:

• SQL Databases
  
• Web Services
  
• SharePoint Lists, Document Libraries, Form Libraries
  
• Content Types
  
• Custom Site Templates
  
• Custom SharePoint Features
  
• Custom Web Parts
  
• ASP.net pages
  
• SharePoint Sites and Pages
  
• Etc.
  

The list can go on. So when doing a deployment, you really need to map out all dependencies of the entire solution and ensure that you deploy everything in the right order.