Hey Mike,
I'm not recommending hosting anything on the cloud for an enterprise. A
few years ago I got coerced into joining the committee for my sons
soccer club and pushed for $100 a year for Jira and Confluence as
opposed to pen and paper and email. It was a hit! Mobile is a disruptive
game changer.
As for tracking bugs to lines of code I have to agree to disagree.
Github and Bitbucket blame features that annotate changes to a commit is
one the big hitters. We have a very mixed code base from 30 year old
HLASM to modern Java and Python. An example of how changes are annotated
in HLASM below.
INTRFACE IPIAESAX,PGEN=GEN,REC=ASAP,SAVE=YES,
+00530000
IPIAPAR=H23K450 CXT04 00540012
L R2,0(R1) .A(parameter
area) 00550004
USING ESAXPARM,R2 .Addressability 00560004
Line numbering and Jira ticket annotations are not good. Source code is
not the right place for history. It was a heavy lift to convince our
seasoned devs of the benefits of Git but they are mostly on board now.
On 9/08/2021 10:47 am, Mike Hochee wrote:
Hi David,
Interesting post. I don't agree either. I think it is more of a multiverse. I
think phenomena like Solar Winds is a good reasons to host your own and not
rely on the admin quality of another vendor's cloud hosting. (AWS has to
employ some of the best cloud admins in the world, yet they unwittingly helped
facilitate Solar Winds) I rather doubt AWS hosts their clouds on Z.
I may have just been fortunate as far as change man procedures and software in
use, but tracking bugs back to changed lines of code has rarely been an issue.
Your DevOps implementation sounds quite interesting and worth looking into.
Mike
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf
Of David Crayford
Sent: Sunday, August 8, 2021 7:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Rocket's Git and GitHub Enterprise
Caution! This message was sent from outside your organization.
I don't agree. z/OS isn't the center of the universe anymore. Most sites run a
stack such as Atlassian Jira, Bitbucket etc which are used by both z/OS and
distributed development teams. The integrations are awesome.
Being able to track a bug ticket to changed lines of code is gold dust.
If you don't want to host Bitbucket you can run it in Altlassians cloud for as
little as $100 a year depending on users. I understand that there are political
issues between mainframe and distributed folks at a lot of sites but that's
just BS which should be solved by strong leadership at the board level.
Everybody needs to be tugging on the same rope!
I've successfully deployed Gitbucket on z/OS but I don't see the point when we
have Bitbucket. We also run Jenkins, Ansible, Artifactory etc. I work for
Rocket and you would be surprised by how many products that you use every day
that are now resident in the z/OS UNIX file system and source controlled by
Git. We do code reviews in Bitbucket and when we merge into master Jenkins
kicks in to run regression tests, scan code for vulnerabilities, build ESCROW
artifacts etc. If anything fails the merge is rejected. This is DevOps. It's
not just some buzz word or fad, it's a useful methodology for project
life-cycles. It's automation which used to take a resource to run manually.
On 6/08/2021 10:51 pm, kekronbekron wrote:
So z/OS datasets are still the source of truth, and just a copy is being made
into GitHub for visibility from the outside.
I'm thinking of implementations that work the other way.
Running Git server on Z**, hooking it to GitHub UI / web service, use GitHub
Actions or other release mechanisms to rollout directly into live Z datasets.
I mean live as in.. the way in which we normally do in Z. Just hooking GH into
the usual current procedures/jobs/REXX in Z.
**Noticed that Github Enterprise Server, the thing where you run the GitHub
Enterprise servers yourself in 'your' cloud, or on-prem on VMware or OpenStack
(lol) KVM... can't actually run in Z.
That is, can it even run in Linux on Z, seeing that currently there's only
OpenStack KVM flavour?
Z can run KVM instead of z/OS but who's going to setup KVM just for this.
- KB
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, August 6th, 2021 at 7:04 PM, Pew, Curtis G
<curtis....@austin.utexas.edu> wrote:
On Aug 5, 2021, at 11:32 PM, kekronbekron
000002dee3fcae33-dmarc-requ...@listserv.ua.edu wrote:
I periodically copy over the current libraries and push the changes to GitHub.
Do you mean push to GitHub and then 'build/deploy/copy over the current
(PARMLIB) libraries using some build workflow?
I have a script in my repository that runs commands like “rm sys1.parmlib/*; cp
"//'sys1.parmlib'" sys1.parmlib” (where “sys1.parmlib” is a directory in the
repository.) After running it I commit the changes and then push to GitHub.
It’s not perfect, but I can get some idea of when a change was made or find an
older version of a member that isn’t working right.
Why is it not perfect, what would you want to work better?
“Perfect” would be if git could manage the actual PDS(E)s, but that seems like
a lot to ask for.
---------------------------------------------------------------------
-------------------------------
Pew, Curtis G
curtis....@austin.utexas.edu
---------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO
IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send
email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to
lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
