The Importance of Integrity

I’m working for a client new to the world of software development and unencumbered by familiarity with development lifecycles and environments. (Not their fault; it just places the onus on us to teach them.) I’m not sure how long my company has been working with them; I just joined the project a couple of months ago.

Somewhere in the past, some percentage of the developers on the project acquiesced to doing development work in their production environment, probably because they were asked to do so to help them with some tight deadlines or urgent requirements. The short term effect was that it helped the client meet whatever deadlines or requirements they had; the long term effect is… disastrous.

When objects are created in K2 (say, a SmartObject and a List View that calls it, as examples), they are assigned a GUID. Each object’s GUID is how the system tracks the integrity of those objects and their associations. For the objects to be promoted to another environment at the appropriate time in the lifecycle, K2’s Packaging & Deployment (P&D) software tackles the job of creating those objects, their relationships, their rules, and their dependencies in the new environment. As you might have guessed, P&D does this principally by using each object’s GUID to ensure the integrity of the software being moved.

If a developer has created those objects in a development environment, then created similar objects in a production environment, P&D will not be able to deploy from one environment to the other because the GUIDs won’t match. It doesn’t matter if the SmartObject is identical in every other way — with the same methods and same properties — K2 knows they are different objects.

How Can I Tell?

The more reliable way to tell if similar objects in separate environments are different is by attempting to package and deploy from one environment into another. The P&D tool will run the analysis and tell you.

Another way to tell requires much less effort, but can’t be used on all object types. Form and view objects which are displayed in a browser can be identified by checking their properties. If you’re using Internet Explorer, simply right-click someplace on the form or view and select Properties from the context menu. You should be able to see a URL (or a partial URL) on the form that pops up. Highlight the entire URL and copy/paste it into Notepad or some other text editor. The URL may contain an ID in the query string similar to this:

Now do the same thing on the same form or view in the other environment, and copy/paste that URL below the first one. Align the ID values to make it very easy to compare the IDs.

[DEV] /Designer/Runtime/Form.aspx?_ID=a11ebaa8-0e9e-4fc8bd05-4addf63d636b

If the IDs match, the objects are the same, meaning P&D was already used to get that object into the different environments; you should have no issue using P&D to move those objects should modifications be necessary.

If the IDs do not match, the objects are not the same, and P&D will throw an error if you try to deploy one object into the other environment.

Now What?

Your only recourse might be to ascertain what is different between the production and development objects; catch the development version up to production if necessary, then delete the production version and deploy the development version.

Let’s return to our example of the SmartObject and the list view. You attempted
to package and deploy them from DEV into PROD and learned the hard way the GUIDs don’t match. So you do the research and determine the SmartObject in both environments have the same properties and methods, but the list view has some expanded functionality.

In this case, you’ll want to reproduce that expanded functionality in the list view in DEV, test it to ensure it works, then, when it comes time to package and deploy, delete the SmartObject and the list view in PROD before running P&D. The software should allow you to deploy the SmartObject and list view from DEV without issue.