Visual LANSA Forum

My team is exploring moving to using version control to help manage our code base and smooth out deployment/rollback conflicts. Has anyone here moved existing repositories to use the VCS Master setup of the VL IDE? If you have maybe you can help answer some questions I have and comment on what your experience was like.

Personally, I am eager to get version control enabled as I see it help with certain problems and reduce risk. However, after a couple painful installs for testing, playing around with new the VCS features, and trying to write up process documents I'm worried the quirks and new process of checking in work may cause too much friction for developers.

My queries and if you have any other tips or comments I appreciate those too:

• Which way did you initialize the local LANSA repo after installation, a normal export/import or did you checkout the yaml files and let the IDE automatically import the code?

• Did you find your deployment process change at all? Either for IBM i Server or VL Clients?

• Did you find any surprises? Such as missing objects or settings?

• Did you have to training team members to learn the version control system of choice? We are going to be using Git.

• If you used VL Frameworks how was working with the extra files?

• How many objects are you working with in your repository?

• Did it just not workout for you? How was rolling back to previous VL IDE installs?

We have been wanting to transition to a VCS for a long time now but have not for one single reason.

The deployment story.

We have a VLF-ONE app with hundreds of components at this point. Our iSeries has two LPARs so we have a DEV and PROD "instance". Currently we use Task Tracking on the DEV box to do all the day to day work. When ready to deploy, we close the task and create an export list that contains all the objects from the closed task and then export the list to a save file. We can then push this file to our PROD instance and import it.

All in all it works really, really well, except we don't have any kind of source control. :S

The issue we have come across with deployments is that there is no fool proof away, that I can discover at least, to only deploy the objects that have changed. With task tracking, it all changed objects are tracked to the task, however with a VCS such as git, we don't have a way to translate the change logs into Visual LANSA.

We were going down the route of trying to create an export list by using the "Deploy To" option in the IDE. Once that export list is created we are ok, but this requires us to know each and every object that was touched and needs to be deployed. This is very error prone IMHO and things are going to get missed.

If there was some way of extracting the commits from a VCS into the IDE so we can issue a "Deploy To" we would revisit it.

If you find a way to handle this, please share!

Joe

jyoung wrote: Tue Feb 25, 2020 1:35 am We have been wanting to transition to a VCS for a long time now but have not for one single reason.

The deployment story.

We have a VLF-ONE app with hundreds of components at this point. Our iSeries has two LPARs so we have a DEV and PROD "instance". Currently we use Task Tracking on the DEV box to do all the day to day work. When ready to deploy, we close the task and create an export list that contains all the objects from the closed task and then export the list to a save file. We can then push this file to our PROD instance and import it.

All in all it works really, really well, except we don't have any kind of source control. :S

The issue we have come across with deployments is that there is no fool proof away, that I can discover at least, to only deploy the objects that have changed. With task tracking, it all changed objects are tracked to the task, however with a VCS such as git, we don't have a way to translate the change logs into Visual LANSA.

We were going down the route of trying to create an export list by using the "Deploy To" option in the IDE. Once that export list is created we are ok, but this requires us to know each and every object that was touched and needs to be deployed. This is very error prone IMHO and things are going to get missed.

If there was some way of extracting the commits from a VCS into the IDE so we can issue a "Deploy To" we would revisit it.

If you find a way to handle this, please share!

Joe

Assuming you are using git (though this could work for other version control systems) is to use branching for feature development and then create a script that generates a user list dynamically. Since the user list is exported/imported via a YAML file like other objects it can be updated via automation. Also since YAML files are named with their short name identifier and grouped by object type you can make a script that get's the branch's changed files and generate a valid user list object. That list then can be used to deliver all objects. In more detail:

## Apply work to a branch

Branches could be equated to tasks in your current deployment workflow. It allows you to make modifications of code on a branch which you can switch out and back to and then also merge into other branches, such as the master branch. So when starting work you would create a branch and all changed files/objects would be only on that branch until deployment.

## Get a list of changes from branch

Once done with work you can run the following command line in the git repository while the branch is checked out to get a list of changed files compared to the master branch (or what ever branch is your deployment branch):
## Use list of files to create a list object

Create a static user list and add objects to it and save. You will notice in the root of the git repository that there is a YAML file for it. I created one with a short name "DEPLOY" and it created a YAML file named `Partition (DEM)/Lists/DEPLOY.lsts.yml` and the content of the file is:
This is a fairly simple file. Using a simple script you could parse out each file's path and name and create an item in the YAML file. I would suggest putting one of each object in the list to see what the types are and if you need any extra information. You can see how a file name could be mapped the first item in the YAML example: `ORDPROC.ORD100.fun.yml` => `{qualifier}.{name}.{type}.yml`.

Run the script while the branch is checked out and it will generate a file for you. Any changes to the YAML file should be picked up by the IDE.

## Use "Deliver To"

Now you can use the list to do a deliver to! If you check in this list before you merge with the master branch you would always know what files were changed in that merge. You could even do deployments from the master instead of the branch too. You may even be able to create an effective rollback strategy since you would have all changes for that merge. A simple one would be to copy the list file, rollback the git repo to the previous commit before the merge paste back the list and deploy after changes are synced, rollback done.