Skip to main content

A community member wrote to me asking my thoughts on K2 and Source Control. That is a topic I see come up often and thought I would share my response with the community at large.

 

K2 & Source Control

 

If you are using Visual Studio, you can use the built in capabilities for source control integration with TFS or GIT to store your workflows and smart object definitions. You can still use it with K2 Studio indirectly you will just have to check it in manually using whatever the tooling is for your source control.

 

If you haven't been building smart objects in the thick client, don't worry just create a new project (or use your current workflow project) and locate your smart objects in the K2 Object Browser. Right click on the object(s) and choose "Save to Local". This will put a copy of the SODX in your project so that it may be checked into source control.

 

Note: If you do this, you will have to edit those smart objects in the thick client. I actually prefer this method due to stability of the designer and the fact I can use source control.

 

In short, processes and smart objects using thick clients is pretty straight forward since you have physical files. One special consideration is that only one developer can check out a project and edit at a time. They must then check in their changes before another developer can open the project. DO NOT use merge or equivalent as it will corrupt your KPRX and SODX files.

 

As for forms, that is more challenging since forms are stored in the database. What I have recommended to my developers is to make a package using Package and Deploy of your forms and views and then check that package into source control. Not as straight forward as the other files in tooling with source control integration, but it as at least something and gives you some level of point in time control.

 

I would be interested to hear what others have done to handle change and release management in their organizations!

 

Hope this helps.

 

S.

Thats great Scott, Even we are following the same approach to keep the version of workflow and process in TFS . Forms we are creating some instant package every day and keeping the TFS document folder . 

 

As of now we dont have any direct source controlling for k2 smartforms as the data are stored in sql . 

 

- Arvind

This is what I've been doing.

I would like to add two points to Scott's great write up:

 

First, in addition to source control it is a very good practice to have a Staging Server.  ALL our packages are published there before production, then Re-Packaged from there into production.  We then make weekly (or so)  FULL packages from the staging server.  This is not a replacement for source control, but is how we have starting making any dot-release changes to Smart Forms.  I've been asking for some more automation feature for P&D so hopefully we can fully script this operation which would make this a very trivial to add.

 

Second, (sorry this is kind of a gripe)

I would like to point out that there is NOT  feature parity between the thick client and the web clients specifically when building Smart Objects.

When building SMO that reference web services that require serialization as part of the SMO method, it is a very good practice to have those serialize into and out of method Parameters and NOT Properties.  I won't get into the reasons in this thread, but would appreciate a discussion about it.

This ability to use Parameters as the target for Serialization and Deserialization actions is not present in the thick client (as of 4.6.11), and in fact, if you bring that SODX local it will break the SMO.

For us, this means that we must use the thin client for SMOs and Forms, then go use the thick client for Workflow.

Full feature parity is not realistic, but thick clients should support, or at least not break, all the features in the web clients.

My point is that our SMO are now NOT in Visual Studio source control (like our processes) which is just one more thing that need "special handling" like Smart Forms.

 

Again, I REALLY wish we had some automation featuere for Packaging & Deployment so we can at least extract packages in a repeatable (and non-user breakable) method.

 

 

Nathan

 

Good to know. To Nathan's point, yes there is a fair amount of feature disparity between the web and thick clients. The parameter thing is interesting as parameters are intended for input only so that idea of in and out could be more of a gap on the web designer side.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings