Upgrading Existing One-Box-Wonder Developer VMs to 5.3??

K
Badge +1

We are currently in the process of upgrading from K2 4.7/5.2 to 5.3


In discussing 5.3 dependencies (OS version, SharePoint etc) we are wondering how to do this, since we have to remain on SharePoint 2013.


Our current developer "one-box-wonder" VMs configuration (what I think is probably typical for others) is the following 
- K2 5.2 (in place upgrade from 4.7)
- Windows 2012
- SharePoint 2013
- SQL 2012 & 2016
- Exchange 2016

 

We know we'll need to split this up due to the conflicting OS requirements of the products (SP2013 is not compatible with Win2016 and K2 5.3 is not compatible with Win2012),

Our question is which would be a better option?
1) Each developer has 2 dedicated VMs:
- VM1: (original DLX) Win2012 with SharePoint, SQL 2012, Exchnage etc..  
- VM2: Win2016 K2 5.3 and SQL 2016

 

2) Or each developer has a dedicated VM for SharePoint
and we stand up a single, shared K2 server that each of the developer VMs have access to? This option poses some issues due to multiple separate farms trying to interact with a central K2 server, and the fact that we'd have to somehow merge each developer's K2 workflows into a single server...

 

What are other developers doing??

 

 

4 replies

M
Badge +11

I only can say that you probably want to develop on supported platform (for the sake of close alignment with you target production environment(s)) - that means you should stick to documented product requirements.
Exact layout of your VMs is up to you, but separate SharePoint box is definitely way more aligned with any production deployment and allows you to do more realistic testing / spot some problems which never occur if SharePoint hosted locally on the same box with K2 server. I would say you need DEV SharePoint Server(s) of required versions and separate K2 server(s) of required version(s). If we don't speak about locally hosted VMs (on developer's workstations), then you just share K2 VM between your developers, or best of all let them connect to it and have developer tools on their workstations without sitting on the server when it is not strictly necessary.

K
Badge +1

Thanks for the reply.

We are talking about locally hosted developer VMs on developers workstations.

While our client environments (dev, staging and production) are all the same (separate SP, Search and K2 servers), our developer vms are not. All deveper VMs are single servers hosted within their own workstation.

I think the safest is to go with 2 VMs hosted locally. I think there will be a lot of potential issues if we go from each developer having a dedicated SharePoint/K2 environment to a shared K2 vm that is accessible to each developer VM. 

I worry about stringtable/variable collisions, package and deployment conflicts, not to mention I'm not sure how the K2 for SharePoint 2013 broker/smartobjects would work given that there's multiple SharePoint farms/webapps all with the same...

G
Userlevel 2
Badge +9

Kent,


I tend to agree with you on the 2 VM approach, as a matter of personal preference. 


I suppose you could also set up a single SP 2013 environment and have each developer have a local K2/SQL server that integrates with their own site collection. Just a thought. There are always nuances to these "one-box-wonder" situations. I understand the safety and convenience factors of having isolated dev environments, where no developer can accidentally step on anyone else's work. And I also understand wanting to consolidate some services for simplicity of maintenance. 


So, I guess I'll give you the age-old infamous K2 response of "it depends!" 


 


Maybe others out there have their own variations of development environments, with isolated and/or shared components? I'd love to hear what others are doing on this topic.


 


Best regards,


Gail

M
Badge +11

Nothing bad with ¨I think the safest is to go with 2 VMs hosted locally¨ - though there may be a bit of overhead in terms of keeping synchronized snapshots of 2 VMs in certain scenarios (the only downside I can think of). As for sharing K2 development server/environment between developers, well, this is fully supported scenario which I guess was in mind when product was designed (can't be other way with server products) - your developers either work on separate solutions (no interference to each other) or collaborate in some way/work on the parts of solution (some process should be agreed on, irrespectively of the product/techonlogy in such scenarios). Though giving them their own VM allows them to be absolutely free/flexible in their development experiments and prototyping of solutions - they kind of fully autonomous in this case :)

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings