What is the difference between dev and cons development configurations

[Former Member]

Hi all,

For every track two development configurations (_dev and _Cons)are created.What is the necessity of two dev configurations .Is there any differnce between these two configurations.

Thanks and regards,

Rajesh

[shreyas_pandya]

Dear Rajesh,<br />

<br />

Yes, for every track two development configurations (_dev and _Cons) are created and not only that, each one of these configurations contain in turn 2 compartments namely active and inactive workspaces.<br />

So your Track consists of totally.<br />

<br />

Inactive Development workspace of your track in DTR Server.<br />

Active Development workspace of your track in DTR Server.<br />

Inactive Consolidation workspace of your track in DTR Server.<br />

Active Consolidation workspace of your track in DTR Server.<br />

<br />

Plus, for each development configurations (i.e. _Dev &#38; _Cons), there are 2 separate Build-Spaces namely Development Build-Space and Consolidation Build-Space.<br />

<br />

Now let's get some more clarity on what happens under the hood, when you perform the Check-In, Activate, Release &#38; finally import your source code changes (wrapped inside the activities that you create for modifications) into Consolidation.<br />

<br />

1) When an activity gets created as a result of any modification it's called "Open Activity". Open Activities are always associated with DTR-Client. Open activities are not available to other developers, not even for the same developer on other machine. To be more precise, Open Activities are strictly specific to the Local Machine's NWDS DTR-Client (their birthplace). <br />

2) When you "Check-In" this activity, it implies that, all your source code modifications present in that Open Activity are copied from your Local Machine's NWDS DTR-Client to the "Inactive Development workspace of your track in DTR Server". Now that activity becomes a "Closed Activity". Closed activities become available to other developers.<br />

3) When you "Activate" this activity, the CBS triggers a build operation to be performed on the source code modification specific to that activity present in the "Inactive Development workspace of your track in DTR Server". On successful activation, your source code will be copied to the "Active Development workspace of your track in DTR Server".<br />

4) Itu2019s also very important not to forget that after a successful activation process, a compiled (built) form of your source code modification specific to that activity is also incorporated into "Development Build-Space" of your track.<br />

5) When you "Release" this activity, it implies that this activity will now be available in the import queue of the Consolidation runtime system of your track.<br />

6) When you "Import" this activity in the import queue of the Consolidation runtime system of your track, there are 2 main operations that are performed automatically,<br />

7) In the 1st operation, CBS triggers a build operation to be performed on the source code modification specific to that activity present in the "Active Development workspace of your track in DTR Server". If the central build is successful then only the same source code will be copied to the "Inactive Consolidation workspace of your track in DTR Server" otherwise the import status will show "Import Failed"<br />

😎 In the 2nd operation, your source code will be now copied to the "Active Consolidation workspace of your track in DTR Server".<br />

9) Itu2019s also very important not to forget that after a successful build process explained in point 7, a compiled (built) form of your source code modification specific to that activity is also incorporated into "Consolidation Build-Space" of your track.<br />

<br />

Now, i am ready to answer your query.<br />

Why the _cons configuration is needed.<br />

Suppose you have performed all the above operations on your activity i.e Check-In, Activate, Release and Import into Consolidation.<br />

Now, assume that afterwards you have made lots of other modifications in other activities.<br />

which you have Checked-In and Activated but not Released and imported into Consolidation.<br />

Now, at this stage if you come across any issues like your Dev-Inactive workspace got corrupted or you have checked-In and activated the code forcefully for which build operation did not happen successfully as a result of which your Inactive Dev Workspace and active Dev Workspace became inconsistent.<br />

In these kind of situations Consolidation DTR workspaces of your track becomes the Saviour.<br />

Because, it is still containing the consistent workspace as the latest modification were not yet imported into consolidation.<br />

So,you can import the same Track but this time select "_cons" to load the source code present in the Consolidation Inactive Workspace.<br />

<br />

One another main advantages of the _Cons workspace is that it never allows any inconsistent source code to be imported in it as explained in point number-7.<br />

So by this mechanism, we have to be rest assured that the .SCA file that will be assembled by incorporating the modifications present in the _cons workspace will always be consistent. And the same .SCA file is transported to the TEST server for further testing.<br />

<br />

Apologies for such a long explanation. But i guess the question indeed demanded it..(^_)..<br />

<br />

Regards,<br />

Shreyas Pandya<br />

<br />

[Former Member]

Hi Shreya,

Thanks a ton.I appreciate your patience for explaining so clearly.

Regards,

Rajesh