Enterprise Integration
As we integrate technology in the enterprise, we see tendrils of GUARDIAN code extending outward to OSS, Windows, Linux, Mac, and towards edge computing. Components like JSON definitions and libraries are starting to be used everywhere – you only want to write your message parser once so that everyone gets the same view. We also see components from other platforms starting to inject themselves into GUARDIAN as we modernize and publish services from our mission-critical legacy applications to services elsewhere.
Central to our capability to support enterprise integration is HPE NonStop NSGit, now part of the HPE Showcase and compatible with HPE GreenLake.
Shared Definitions
Most importantly, there are interface definitions that need to be consistent no matter where they are used. These include WSDL, SOAP, REST, and C header files that application builds use, and consume on every platform that communicates with every other platform. Security and tokenization definitions also are shared between components and systems as inflight data moves from one system to another and rests in databases, protected from prying eyes. Consistency and correctness must be accurately deployed and verifiable for the enterprise to deliver reliable services to customers.
This sharing of key communication integration components is a crucial reason companies are deploying git on every personality, VM, and platform in the enterprise. NSGit is at the heart of enabling GUARDIAN applications to participate and expand not only their usefulness but their lifespans and the huge investments companies have made in them. Processes built around GUARDIAN applications are high-value commodities that are not cost-effectively replaced without massive risk.
Background Wisdom from the git Community
There are huge debates within the git community on structuring repositories that centre around answers to the big question that every organization ends up asking: how do we structure our repositories? The answer varies from team to team but usually comes down to two choices: go big or go small. About ten years ago, the answer was overwhelmingly go small, make many repositories, once for each module. Initially, it was convenient and easy for developers to use, but as applications age, there are these really annoying things called “support calls.” Each support call can end up with tickets that lead to fixes. When you have many repositories, you end up with a ticket for a distinct fix in each repository – and of course, requirements to test each fix to each ticket. In one situation, Google found that even trivial fixes were ending up with many dozens of tickets per issue, becoming increasingly unmanageable. So, the pendulum swung back to where it started early in git’s history, to larger more all-encompassing repositories that covered entire applications. Commits became larger – something git is exceptionally good at –the number of tickets dropped to more reasonable levels, and time-to-market and cost-to-market went down. Only time will tell as to whether the pendulum will swing back, but for now, this go large approach serves our own community well.
There is a drawback – A drawback if you are not on NonStop because you would not have NSGit.
Capabilities Shown at NonStop TBC 2021
At the NSGit demo (TBC21-X11), we saw how to structure a multi-platform repository that happened to use a GUARDIAN application at its core. Ironically, the sharing of content between platforms comes down to selectively ignoring what you do not want to see in places you do not want to go, in two critical ways: ignoring non-GUARDIAN code, and conditionally ignoring files.
Ignoring Non-GUARDIAN Code
One way of managing a large repository is to selectively ignore parts that you do not want or need. Enter the .nsgitignore file: a simple ignore directory declaration using:
.
as the entire content of that file in any directory you do not want to see in GUARDIAN, will tell NSGit not to associate it with a sub-volume. You can do this for Java code, OSS code, Windows, etc. We showed this in our demo by excluding our Web Server and Web Content folders.
This allows GUARDIAN developers to focus on what is relevant to our application and job functions and ignore what we do not have to see.
git itself has a similar concept, added in the past few months called Sparce Checkout. Sparce Checkout is harder to configure than NSGit but accomplishes the same thing by omitting specific directories that are not needed in certain situations. A good example of its use for us is in production, where we only would care about release artifacts and do not want to see source code – unless there is an emergency requiring production debugging or forensic analysis of a breach of some kind, the kind we never want.
Conditionally Ignoring GUARDIAN Code
Another way ignoring content helps us is during development. Developers are primarily interested in delivering changes in source code, at least for their immediate jobs. Release objects and intermediate objects do not factor into code delivery if you are a developer. So, we have two scenarios for our objects – development and production builds – where we must treat files differently. This is another situation where things are somewhat more difficult for git, but easy for NSGit and again comes down to how you manage ignoring files. In the demo, we showed that some files (release objects) are specifically ignored by naming them in the .nsgitignore file. We can modify the conditions where and when those files are ignored by specifying when not to ignore them. For example:
* exclude=release,code 500
This entry ignores all code 500 files (objects on L-series) unless a release is under construction. NSGit has a common command argument, –ignore-condition=release, which causes the ignore directive to be ignored. So, during a Jenkins build, we would specify this argument and the object would show up in git and then be deployed on our release branch as we did in the demo.
Selectively Ignoring Previously Released Objects
Another highly valuable capability, also involving ignoring content, used during what our community calls incremental releases. These releases contain only the items that actually changed, making incremental testing more viable and deployment more cost-effective, in some circumstances. We rarely do this sort of release for edge devices where deployment systems cause the whole application to be flashed into device EPROMs, but it is really an essential part of deployment processes in the massive GUARDIAN applications that our community manages.
We demonstrated the viability of using automation to determine whether object files change in significant ways or in sometimes do not change at all using NSGit’s custom object difference engines. A simple evaluation using the nsgit diff command speeds the construction of incremental releases by letting the automation decide whether to accept or ignore an object. This automation speeds up time-to-market and reduces error rates by not forgetting to include crucial components.
Other git and NSGit Benefits
With simplicity and low touch rates as starting design goals, git and NSGit stay out of the way of developers. Aside from information query commands, a small set of four key commands, add, commit, push, and switch, allow developers to focus on delivering features and fixes rather than worrying about the details of their version control system. Manual lists of what files were modified are now things of the past.
NonStop TBC 2021 Summary
What our team demonstrated during the conference, both in the demo and presentation sessions at NonStop TBC 2021 are the ways git and NSGit benefits organizations by integrating GUARDIAN into the enterprise. We showed a controller/agent Jenkins configuration where part of the application builds in GUARDIAN and other parts built under Linux while sharing common definitions. We showed how we can reduce human interactions and touchpoints with the code during build and deploy phases to cut downtime to market. And we also introduced NSGit into the HPE Showcase program, as a valuable strategic component in the NonStop DevOps ecosystem.
For more information, please reach out to the author at randall.becker@nexbridge.ca.
Be the first to comment