Skip to main content

Hello,

I have been setting up RDOi for Eclipse/RDi. I am using the plugin version 8.2.800 and RDi is on 9.8. For Rocket DevOps Core for IBM i, we are on version 10.2 (no PTFs) .
Despite 8.2.8 not being listed as compatible with RDi 9.8, everything appears to be working correctly.

Here's what happens currently to promote from DEV to ITG via greenscreen:

  1. stracms
  2. opt 2 "Work with objects by developer"
  3. opt 7 on program to promote to ITG
  4. Enter.. then "Specify Promote Options" has Deploy from ITG as Y
  5. Define Deployment Set, ect . . . 

Now, when I do the same thing via RDi:

  1. Right click object in DEV -> Check In, add comment, Select create dependent objects in environment . . . 
  2. Hit OK, then RDOi will move that object to ITG and build it into that environment.

My question is: Can I define a deployment set via the RDi method the same way I can via greenscreen? Is that something in a newer release of RDOi for RDi that I'm missing out on until we update from 10.2?

Another thing to mention, when doing promote via greenscreen, the end result is that the source is kept in XINT/XQUA library, and the program is kept in YINT/YQUA library. RDOi keeps all in XINT/XQUA. The CRTSQLRPGI commands that RDOi uses for RDi and greenscreen in my two promote tests were identical, so I assume that the source and program split is because of the deployment set.



------------------------------
Jake Maguire
Software Engineer
Rocket Forum Shared Account
------------------------------

Hello,

I have been setting up RDOi for Eclipse/RDi. I am using the plugin version 8.2.800 and RDi is on 9.8. For Rocket DevOps Core for IBM i, we are on version 10.2 (no PTFs) .
Despite 8.2.8 not being listed as compatible with RDi 9.8, everything appears to be working correctly.

Here's what happens currently to promote from DEV to ITG via greenscreen:

  1. stracms
  2. opt 2 "Work with objects by developer"
  3. opt 7 on program to promote to ITG
  4. Enter.. then "Specify Promote Options" has Deploy from ITG as Y
  5. Define Deployment Set, ect . . . 

Now, when I do the same thing via RDi:

  1. Right click object in DEV -> Check In, add comment, Select create dependent objects in environment . . . 
  2. Hit OK, then RDOi will move that object to ITG and build it into that environment.

My question is: Can I define a deployment set via the RDi method the same way I can via greenscreen? Is that something in a newer release of RDOi for RDi that I'm missing out on until we update from 10.2?

Another thing to mention, when doing promote via greenscreen, the end result is that the source is kept in XINT/XQUA library, and the program is kept in YINT/YQUA library. RDOi keeps all in XINT/XQUA. The CRTSQLRPGI commands that RDOi uses for RDi and greenscreen in my two promote tests were identical, so I assume that the source and program split is because of the deployment set.



------------------------------
Jake Maguire
Software Engineer
Rocket Forum Shared Account
------------------------------

Jake,

Question 1: The interface is working as designed. The reason for this behavior lies in the fact there are 2 deployment options (Deploy, Live) The Deploy option allows for user intervention during the initiation of an RDOi deployment while Live was not meant to allow user intervention. That is, the deployment would be performed as configured.

For example, when initiating a deployment with the Deploy option a user can select whether to deploy to all or a subset of the targets assigned to a deployment profile where as with Live installation you cannot make that selection, the deployment will be for all the targets as configured.

That is why the products that interfaces with RDOi for the promotion function (RDOe, Eclipse Plugins, Jira, etc) only allows the Live deployment option because user intervention is not possible like it is when using the 5250 green screen. To be able to initiate a deployment you'll need to change the Type of the deployment profile/Target from Deploy to Live. In that case, during the promotion the option Install live from QUA would be set to Y instead of Deploy from QUA.

Question 2: We would need to get more details about you RDOi setup to give a more detailed answer. Generally there are only one library defined for ITG/QUA because these libraries are considered transitory (object/source is deleted after promotion) while for your live test environments the object/source may be in a different libraries. You may also be configured for source not to be deployed, in which case the source would only be stored in the related environment library.



------------------------------
Newton Beckford
Senior Technical Support Engineer
Rocket Internal - All Brands
Mississauga ON CA
------------------------------

Jake,

Question 1: The interface is working as designed. The reason for this behavior lies in the fact there are 2 deployment options (Deploy, Live) The Deploy option allows for user intervention during the initiation of an RDOi deployment while Live was not meant to allow user intervention. That is, the deployment would be performed as configured.

For example, when initiating a deployment with the Deploy option a user can select whether to deploy to all or a subset of the targets assigned to a deployment profile where as with Live installation you cannot make that selection, the deployment will be for all the targets as configured.

That is why the products that interfaces with RDOi for the promotion function (RDOe, Eclipse Plugins, Jira, etc) only allows the Live deployment option because user intervention is not possible like it is when using the 5250 green screen. To be able to initiate a deployment you'll need to change the Type of the deployment profile/Target from Deploy to Live. In that case, during the promotion the option Install live from QUA would be set to Y instead of Deploy from QUA.

Question 2: We would need to get more details about you RDOi setup to give a more detailed answer. Generally there are only one library defined for ITG/QUA because these libraries are considered transitory (object/source is deleted after promotion) while for your live test environments the object/source may be in a different libraries. You may also be configured for source not to be deployed, in which case the source would only be stored in the related environment library.



------------------------------
Newton Beckford
Senior Technical Support Engineer
Rocket Internal - All Brands
Mississauga ON CA
------------------------------

Newton, 

Thank you for the response. The reasoning behind the behavior makes sense to me. Now, when you say "the deployment would be performed as configured", I am not finding a place via the RDi plugin to do any deployment configuration or set a default deployment set for the object. I understand what you mean by changing the type from deploy to live for the deployment profile, but how can I make the "check-in" and "promote" utilize that deployment profile over a different one?



------------------------------
Jake Maguire
Software Engineer
Rocket Forum Shared Account
------------------------------

Newton, 

Thank you for the response. The reasoning behind the behavior makes sense to me. Now, when you say "the deployment would be performed as configured", I am not finding a place via the RDi plugin to do any deployment configuration or set a default deployment set for the object. I understand what you mean by changing the type from deploy to live for the deployment profile, but how can I make the "check-in" and "promote" utilize that deployment profile over a different one?



------------------------------
Jake Maguire
Software Engineer
Rocket Forum Shared Account
------------------------------

Hi Jake.

Pls open a support ticket and we'll be happy to review your RDOi configurations to support use of the DevOps plugin for RDi.  Regarding this, "...not finding a place via the RDi plugin to do any deployment configuration", the plugin is a development utility.  The configurations for external file system updates on the i are managed in the RDOi application itself based upon 'rules' for the repository and management decisions made during the registration of your code.

Best, 

d



------------------------------
Dale
L3 Support for the enterprise bits, portals and plugins...
Rocket DevOps (formerly Aldon)
Somewhere on the Oregon coast...
------------------------------