1. Christopher Craft
  2. PowerBuilder
  3. Friday, 23 October 2020 16:54 PM UTC

As I continue to research Git and PowerBuilder I am trying to understand the best setup.

1) Repository - There have been some articles saying the GIT repository name must be the same name as the workspace but when you select the 'Add to Source' it allows you to have the repository name different than the workspace. And even the 'Connect to' allows them to be different. Is this now ok to do? Should we still keep those names the same? Seems a little restrictive but if there is a reason then I will follow it.

2) PBL - To source or not to source...that is the question. I have read that the PBL should only be pushed the first time and then everything after that is just importing the changes into the PBL. What happens if you go back and forth between multiple releases? How does the PBL deal with objects being removed and added? What happens when you get the latest release the first time (ie. new developer) and you already have multiple releases out there? Our current model is we flag the PBL as a 'product' and it gets checked-in for the final release so when you go get the objects for the next release then the PBL is up-to-date. This makes it so only changes for the current release need to get imported. What is the best practice here for Git and PBLs?

3) When modifying code we always associate a task to the work when we do the check-out. Once we are done with that piece of work we check it in and sign off the task. This allows the build process to pick up just that change. Since Git does not have a Check-out/in then how do you associate changed code to a particular work item? We are always working on multiple features at the same time so I can't just have a bunch of changed code out there and not know what the change is associated to.

Thanks for any input,

Chris Craft

Accepted Answer
Donald Clayton Accepted Answer Pending Moderation
  1. Friday, 23 October 2020 19:50 PM UTC
  2. PowerBuilder
  3. # Permalink
3
Votes
Undo

Hi Chris,

I'll try to speak to the issues you mention below.

1) Repository - There is no technical reason to name the repository after the Workspace, just understand if you choose to Branch the repo you will be branching the entire repo, so it's best not to place multiple Workspaces in one repo.  But it can be named anything that makes sense to your organization.

2)  PBL - there are a variety of answers here, so "it depends".  Ideally it is best if the PBL is thought of as a semi-disposable artifact.  You can persist them in a repo, but none of the SCCs out there deal with things like developers deleting objects from PBLs or moving objects between PBLs gracefully.  In a true CI/CD scenario, you should pull the workspace/target(s) from the branch of the repo, bootstrap the PBLs using ORCAscript, do the build for the branch, report success/failure through the organizational SOPs of the CD process and then either put the newly rebuilt PBLs back into the repo for other developers' convenience or archive them in some other way.  If the .PBLs are placed back in source then developers can pull them down daily and know they have the latest and greatest.

The second option is to "upload PBLs" to SCC after objects are deleted or moved or PBLs added or deleted.  This is easier (i.e., less disciplined) but this can be just as effective for smaller teams or one person projects.  Regardless, with Git, developers must learn to "pull" before they "push" or they will inadvertently branch the repo which will create unnecessary chaos.

For CI/CD you'll also need a build automation strategy, be it Jenkins, Bamboo, Octopus Deploy, etc.

 3)  Tracking code changes to bugs/feature requests requires additional tools.  If you use Bitbucket for Git you can integrate Jira for issue tracking and Agile development.  That's a great configuration.  Similar capabilities exist in MS Azure Dev Ops but are perhaps not as robust.  Other solutions can be cobbled together using various different tools. 

I will geek out for a minute and talk about  the Capability Maturity Model (CMM) & its Levels in Software Engineering.  To get to CMM level 4 you need to not just track an issue to the code change but also the time required to get from issue to code change.  That way you get some labor metrics that you can put into a feedback loop so you can better estimate effort and thus cost, which gets an organization to a high CMM Level 4 and on the way to CMM Level 5.

 

 

Comment
When you use Git it organizes exported source objects into a ".ws_objects" folder which is hidden in the repository, like the .git folder. So there should not be a conflict if you have two objects with the same name in different .PBLs. There is an option in the PB System Tree at the PBL/Target level to "Upload PBL" if you want to upload reorganized PBLs into the repo. Typically .PBLs are not pushed back to the repo unless you explicitly do so. Please refer to the ORCAScript documentation on how to bootstrap .PBLs if that's what you would like to do.
  1. Donald Clayton
  2. Friday, 26 February 2021 22:14 PM UTC
I think I do not understand clearly.

I have som PB application in which I have say PFC. That application is in GIT. (In git repo are pbls and ws_objects folder.

If I commit into GIT and someone update his source from git. PBL are changed on his side after he update sources.



If I want to update pbls (say update PFC with new version) I will replace old pbls with newer one.

But after that It will not regenerate ws_objects automaticaly and I did not find any way (in power builder) how to do that.

What is recommended way of update whole PBL in project which is in GIT SC? Is it delete WS objects, update pbl, then use some orcascript way, or there is some other way to do that?

Sorry for my english, hopefully you can understand me better what I'm trying to achieve.



Ales
  1. Aleš Vojáček
  2. Friday, 5 March 2021 16:54 PM UTC
There really is no good way to handle PBLs in git. I'd say the least-worst way to update PBLs in GIT is not to do it. :) What i mean by that is that you need to update the code, not the PBLs. Only add PBLs to source control with your initial commit or whenever you need to add a new one.

If you overwrite PFC PBLs with a new version, the actual code that is held in ws_objects and thus GIT is not updated. If you update the code in ws_objects, the PBLs are not updated automatically but using the "Refresh" command in PB will load any changes from ws_objects into the PBLs.

If you want to update your PFC from PBLs one way I could think of would be to create a new workspace that is not under source control, add the new PFC PBLs to that one and export all the objects to one folder per PBL. Use the library painter to select all objects inside a PFC PBL and export via right-click; pick a folder and hold ALT+S (or whatever the hotkey for "save" might be on your system) until all objects are exported.

Then delete everything inside the respective folders (say pfcapsrv.pbl.src etc) inside ws_objects of your target workspace that is tracked via GIT. Use a git client program to commit and push the changes.
  1. Benjamin Gaesslein
  2. Monday, 8 March 2021 08:30 AM UTC
There are no comments made yet.
Donald Clayton Accepted Answer Pending Moderation
  1. Friday, 5 March 2021 19:21 PM UTC
  2. PowerBuilder
  3. # 1
0
Votes
Undo

There is a "Right Mouse Button" option at the .PBL level or higher to "Upload PBL".  Technically, this is a local repo "commit" which then needs to be pushed to the remote repo.

You will likely need to remove and re-add the objects to Git SCC for the PFC and PFE .PBLs and then commit and push to get everything needed to developer #2.

Comment
Ok,

You mean remove PFC PFE from project, remove exported object, add new PFC PFE pbls and then commit / push? I will try, but when I did that I think that it did not expot objects for new pbl added to workspace.

I will try agani.

Thank you
  1. Aleš Vojáček
  2. Monday, 8 March 2021 12:07 PM UTC
Not exactly. Here are the steps:

Make sure you are on a "clean" remote repo w/ no uncommitted/unpushed changes

Remove all the objects from the PFC and PFE layers from SCC

Replace old PFC with newer PFC.

Do a full rebuild.

If you get this far,

Add the PFC/PFE objects back to SCC

Commit these objects

"Upload" the .PBLS, which is actually a commit of the .PBLS

Push this Changeset to the Origin branch.

  1. Donald Clayton
  2. Monday, 8 March 2021 17:23 PM UTC
Ok,

got it and really thank you.

On which exact step are PFC/PFE objects extracted (ws_objects created) for newly added pbls?

That is what did not happen to me. No exported objects from newly added pbls.



Thank you Ales
  1. Aleš Vojáček
  2. Monday, 8 March 2021 17:50 PM UTC
There are no comments made yet.
  • Page :
  • 1


There are no replies made for this question yet.
However, you are not allowed to reply to this question.