Skip to main content

Hi,


I've got several questions concerning solution deployment from an isolated development environment.


(I read the K2 Deployment Package section in the User Guide but did not find answers to this questions).


If I understand correctly, different deployment targets  can be configured through so called evironments with corresponding environment variables.


Q1: Do I need an active connection to let's say the production environment to design a solution?


E.g. I am using a SharePoint Events Process. To assign a value to the Sharepoint URL I use an environment variable. If I assign a non-existing URL to this variable I'm asked for a SharePoint Design Time Variable (I assume that this value is used temporarely to validate the process).


Q2: How are environment variables handled during deployment? Are they handled as strings?


E.g. If one is refering to a SharePoint list - does K2 handle the entered variable as string (=listname) or does K2 use other identifiers (for example GUIDS, Sharepoint "internal" names, etc.)


Q3: How are users in a process handled?


When I open the user browser, I can see no differentiation between development or production environments. How would I handle different domain names e.g. developmentadministrator vs. productionadministrator? Should environment variables be used instead of entries in the User Browser? Are users refered to as strings or e.g. by their SIDs?


Q4: How are extensions to environments handled?


When I add environments or environment variables in a disconnected development environment and generate a deployment package, are those extensions packed into the package and deployed with the msbuild extraction?


 


Thanks a lot for clarifications,


DD

Q1.  Not neccessarily no.  But there are cases where you can not perform certain actions without a connection to the environment.


 


Q2.  Yes, the environment variables are copied to a process string table


 


Q3.  You can do this with security.  Not giving some users rights to view


 


Q4. I am not sure about that one, we may need to get more clarification. Anyone?

I'm not sure I understand all of your questions, but I'll see if I can provide some answers.


Your first statement is correct.  Different deployment targets are created by using the Environment variables.  You can define different environment names on your dev server and then use them in deployment packages. 


 Q1:  You need an active connection to an environment.  Developers almost always connect to the development environment.  You do not need to connect to the production environment from Visual Studio unless that is your only environment.  When you are connected to the development environment, even though the Environment variables say Development or Production (or whatever environment you create) they are really stored on the development server.  The msbuild package contains the environment variables for all the different environments and you can switch between them to deploy the specified values to a server.


Let's take your SharePoint example.  With the Environment set to development you could create a field called 'HRSharePointSite' and supply the URL to your development SharePoint site for Human Resources.  You would use this environment field in your SharePoint event.  All the workflow knows about is a variable caleld 'HRSharePointSite'.  At some point you would change your Environment setting to Production (or another environment) and edit that field so that the URL points to your production site.  When you deploy to production, you would specify the production deployment parameter.  The environment variables would be set with their production values, in this case your production SharePoint URL.  The workflow does not have to change when moving from one environment to another because it is referring to a variable called 'HRSharePointSite'.


Q3:  It is almost never a good idea to use actual users as destinations.  If you assign a client event to domainfred because Fred is the VP of HR and then Fred moves to accounting you would have to update and redeploy your process.  Instead, it is generally better to use roles in destinations.  The members of a role can be defined administratively using the management console.  You would define a role, like 'VPorHR' and use it as a destination in a client event.  Using the management console allows you to change the members of the role without touching the workflow.  The same principle applies when moving between environments.  In development, role VPofHR might contain one of your test users, while in production the role would contain the real person in that role.


 

Great - Thank you very much for the clarifications.

Q1: As you said I need active connection to environment where I need to deploy? So is there any way to deploy to K2 server which I haven't connection whit his.


Thank you very much
Darko 

You need to create a deployment package and deploy it on the server using MSBUILD.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings