devopsy.kinsta.cloud

Tag: source code management

The Case For an API-First SCM

Somewhere around a decade ago, about the time DevOps really started to manifest, we began seeing technology companies—including some of the largest ones today—investing heavily in their APIs.

API-first companies managed to rapidly gain widespread adoption because of the benefits of being API-driven. Everything from automation and scalability to flexibility, performance, speed and monetization. Once DevOps thinking made it increasingly clear that automation would solve problems like human error and increase performance and velocity, creating more machine-to-machine interaction became a critical factor in software delivery—because the problem in the technology world was not innovation, but rather integration.

Twilio is a prime example. The company became famous for its API-driven approach to customer management and even had a famous Silicon Valley billboard trumpeting their success. They changed the game for customer communication for some of the largest companies in the industry, from Netflix to DoorDash to Coca-Cola, by making communication completely invisible to users. These APIs largely served developers by unifying communication on the backend and providing powerful customer-facing capabilities on the business side. But they’re not the only ones.

API-driven companies managed to disrupt entire markets nobody imagined could be disrupted, such as Stripe for payment processing and Slack for immediate communication (their former head of developer relations, Amir Shevat, said that Slack’s developers were literally measured by their API’s active tokens). Companies that harnessed the power of their APIs saw unprecedented growth over the last decade due to the integration power they unleashed.

Today, there really is no self-respecting dev-first technology that doesn’t invest heavily in the robustness of its APIs. There are even entire companies today built around API integrations—from marketplaces like Rapid API to security companies like Akita Software to companies like Kong that focus solely on simplifying API gateways.

The API-First Dev Tool Revolution

The same transformation that disrupted various business industries is now beginning to take center stage in the technology and dev tools space. This is also part of the developer experience revolution that is the stimulus for all the nifty dev tools in the first place. As developers become the new decision-makers—masters of their own domain—and are no longer being forced to adopt and use technology someone else purchased for them, the experience of using these tools impacts their choice of whether or not to add these tools to their chain. This means that those creating the tools today need to deeply understand the developer’s workflow and optimize their products for this user persona.

This very same evolution that typical tooling underwent is now impacting age-old tooling in the developer ecosystem—and developer pain and friction are starting to come to the forefront. This includes the need for better and more robust API capabilities, “as-code” (infrastructure-as-code, testing and security) tooling, low-code/no-code and code variations and much more.

It’s interesting to see that, even with the cloud-native and DevOps revolution, our most core developer tool—our source code management—hasn’t really changed much in the last 20 years. Git remains ubiquitous, but its design is optimized for developer workflows from two decades ago. It’s long past time for an API-first SCM, and there are a number of use cases that can benefit from better APIs.

Evolution and Anatomy of APIs to be Git-Native

Even with the most exciting innovations we’re seeing from Git SaaS tools like GitHub and GitLab—from Co-Pilot to Codespaces, pipelines and more—they’re only as strong as the technology they are built upon. As the world evolves, this fundamental weakness is proving to be a sort of kryptonite.

Despite Git being an old-school, monolithic tool with proprietary protocols, Git hosting providers like GitHub, GitLab and Bitbucket have invested a lot into making their services API-driven to cater to tool integration. True, each has its own API, which drove some players integrating with the service (especially in the early days) to integrate via an SDK rather than an API.

GitHub itself provides a variety of APIs—from the simpler REST through the more elaborate GraphQL. These APIs provide you with the ability to do pretty much anything, but are somewhat cumbersome for some use cases. To deal with the core Git functionality, you are required to directly manipulate objects in the Git database.

Code Deployment and GitOps

As engineering organizations grow, the need for greater control of code and infrastructure resources has become a real pain—and this is where GitOps provided the methods and the tools to support automated policy management at scale. This automated policy and governance is largely enabled, machine to machine, via APIs, and many of its controls are built on code and configuration files that are hosted via Git (hence its name: Git Operations).

When using this methodology, a configuration change is first committed to Git (as the single source of truth that will apply changes in all the relevant places). Only then does this trigger automatic processes to apply these changes universally. In some cases, these automatic processes have to commit files to Git via API.

Another area where SCM APIs play a key role is versioning and release management. DevOps teams need to manage the release of new versions of their applications, including creating release notes, tagging releases and creating release branches. These processes, which sometimes take place multiple times every day, include many steps and require accuracy—a comprehensive suite of efficient APIs is critical for such an operation.

UX Customization

Today, there’s a huge diversity of stakeholders in modern engineering processes, particularly in the context of game development, but this is also true in any kind of web-based or UI-based engineering, as well. Today, product and design are an integral part of engineering processes, but Git still remains the domain of developers.

There are times when you’d like to have a unified interface for your asset management that pulls data from multiple APIs and sources—such as Git for source control and Google Drive for large files. The added benefit is to abstract and decouple the underlying technology from the user experience and interface so that users can be free to migrate and move between their technologies of choice. This is true whether at the SCM or the storage level without having to change the interface that the team is accustomed to.

APIs that efficiently perform the full set of SCM functionality allow developers to use a single backend for managing code versions while still providing end users with the desired experience, regardless of what that might be.

Versioning-as-a-Service

SaaS products have made it significantly easier to manage and maintain our services through simple UIs and dashboards. However, this simplicity also has a tradeoff. Have you ever made a simple configuration or code change, quickly regretted doing so and then attempted to revert it via your SaaS console? In most SaaS apps that aren’t managed as code, this happens all the time—from Okta to Datadog and many others. Without the benefits of “as-code” and the version control that comes with it, reverting changes is nearly impossible.

The most you can achieve is “undoing” a previous configuration—if you can still catch it with a CTRL+Z—simply because engineering didn’t bother (or did not have the resources) to implement versioning. Imagine if this could come as a service for all of your SaaS applications!

For software developers, API-based version control will unlock the possibility of easily incorporating rich version control capabilities into their product—in the same way they can currently use other capabilities such as database, file storage, etc.

The World is Ready for an API-First SCM

TL;DR: API-first models have delivered some of the greatest innovations that ‘dinosaur’ industries—from payments to communications—needed to move faster and do so securely. It is almost laughable that the technology industry has inherent limitations due to a core technology that has a legacy design. This should not be a technology limitation we should accept.

Our source code should be able to be controlled, manipulated and transformed via API to remove human toil from places it isn’t really needed and free people to focus on higher-order problems. With the widespread adoption of generative AI and smarter machine overlords, we’ve discovered that there are many formerly manual tasks that we can offload to machines. Free SCM APIs to unlock the next generation of innovation—because soon there will be more machines than humans to manage them. APIs are the key to tapping into this power.

June 16, 2023
The Secret to Secrets Management: Reduce Source Code Vulnerabilities

We are in the cyberattack age. From Microsoft to Crypto.com, no company is completely safe from malicious attackers, and it seems as if a new major cyberattack is announced weekly, if not more frequently. As more companies not only go digital but expand their digital offerings and initiatives, there are more opportunities for cyberattackers. Security teams within IT organizations are hard at work to ensure that their company isn’t next in the headlines. However, as the tech world moves to everything-as-a-service (IaaS, PaaS, SaaS, etc.), the move toward everything-as-code is happening in tandem. As a result, many developers are unknowingly keeping sensitive data (secrets, passwords, certs, keys, etc.) stored in Git source code repositories. This information is often pushed to production which puts sensitive information at greater risk of exposure.

The good news is there is a way to ensure that secrets are locked tight within source code. Let’s explore the complexity and realities of securing source code today and how to take the guesswork out of finding at-risk code that could land your company on the front page of the news tomorrow.

Secrets Management is Challenging and Costly

Sophisticated cyberattackers will stop at nothing to breach valuable data assets. Secrets leaked from source code make it easy for threat actors to access applications using the same credentials intended for legitimate purposes.

At the pace of continuous software development, developers must move quickly to build applications. However, security teams that are expected to prevent breaches are not often well-versed in all facets of the software development life cycle (SDLC). This becomes an issue as the number of lines of code (and the secrets kept within) rise alongside the number of apps developed. According to a recent report from 1Password, “two in three (65%) IT and DevOps employees estimated their company has more than 500 secrets.” And, according to the same report, “the average cost of a secret’s leak is $1.2 million. Poor secrets management can result in organizations losing $8.5 billion annually.” Secrets are vital to building any connected application or process. If hard-coded or left unprotected in source code, the proverbial keys to the kingdom are at risk of exposure—as are your loyal customers.

It’s clear that source code security should be a priority for security teams and DevSecOps professionals. Let’s examine how they can achieve this without sacrificing developer productivity.

How to Reduce Threats Through Secrets Management Best Practices

Manually searching source code repositories for vulnerable secrets can be almost impossible. However, there are some best practices to follow to ensure vulnerabilities are caught early and often:

● Identify and remove secrets in code: You can’t protect what you can’t see. It’s important to have visibility into source code to be able to see where vulnerabilities may exist. There are a few ways of potentially going about shining a light on vulnerabilities. One is through manual scanning of source code, but this takes away valuable time developers could be spending on more innovative tasks. There are also some open source solutions that can help with scanning source code repositories, but as with everything open source, this means developers will have to maintain it (keep it up to date, integrate it, etc.). Instead, security teams should consider looking for a unified toolchain platform to help with source code vulnerability identification and remediation.
● Alert and remediate in code repositories: Provide a fast feedback loop to a developer or DevOps engineer before releasing code into production. Remediation should happen at the time of commit. The idea here is to block secrets from being committed to your source code repositories in the first place.
● Adopt a secrets management tool: Don’t store secrets or binaries within source code—nothing but code should be in your source code repositories. Remove secrets to a secrets manager (i.e. HashiCorp Vault), keys and certificates manager (i.e. Azure Key Vault), etc. Modularize and isolate these managers, but make sure they still communicate with each other so that they don’t expose secrets.

As cyberattacks continue to increase, it is imperative that security teams take a hard look at their source code to ensure that it is locked up tight. Keeping secrets out of source code entirely is recommended in theory but difficult to ensure in practice. Following the above best practices will help reduce the risk of exposure of sensitive data and reduce the risk of losing loyal customers and revenue dollars.

August 30, 2022
Source Code Management Best Practices
Source code is, of course, the foundation of any software development practice. Managing that source code is the first task tackled by modern software development pipelines, with all subsequent stages of the pipeline dependent on the source code for their success and functionality. Thus, it is critical that source code is properly managed without introducing bottlenecks or defects into the delivery pipeline. To do so, there are some best practices to follow when interacting with source code.

Regularly Commit Changes

While this may seem obvious, commits often are done sparingly, as most developers tend to commit only after a significant change. The commit frequency depends on the workflow and it is acceptable to commit only after major modifications if that commit triggers another task.

However, it is better to commit changes—even minor ones—regularly. It not only keeps an auditable history of changes but also enables easy comparisons between commits for troubleshooting and ensures that the code is up to date with the version control system (VCS). However, it does not mean that users should make commits for every small change; instead, adapt a development style that includes frequent commits as part of the workflow. Even if there are many commits, most VSCs provides users with the option to combine multiple commits to a single commit using a rebase for better management.

Always Ensure That the Repository is Up to Date

Most of the time, development is a team effort with multiple developers working on a single codebase. Thus, there will be frequent updates to the source code. So it is always advisable to use git pull or fetch to obtain an updated copy of the code before making any changes. This practice not only mitigates merge conflicts but also helps users to avoid errors while pushing the code, such as ‘failed to push some refs to‘ errors which occur when the local copy of the repository is behind the remote.

Create Detailed Commit Messages

Commit messages should be meaningful and include the ability for anyone reading the message to grasp the reason behind the commit quickly. It does not mean that users should create lengthy commit messages; instead, they should describe the commit in a concise yet meaningful manner. The commit message should include why the code was committed and not how it can be identified by comparing the files.

A good commit message can include details such as bug fix ID or requirement ID, which reference the specifications of that code change in project management platforms like Jira and Azure Boards.

Review Changes Before Committing

Always make sure to review the code before making commits—this is imperative if you are committing to a shared repository. Typically, code reviews are a part of the delivery pipeline before merging code with the master branch or a specific repository via a review system or a pull request.

Code reviews put a second set of eyes on code modifications and help detect any issues in the code. It also acts as a quality control mechanism that helps organically improve the overall code quality while helping to increase the awareness of each code change.

Implement a Proper Workflow

A proper workflow with standardized practices must be implemented across the development team even while using a source code management (SCM) tool. Some considerations for a standardized workflow:
- Decide on a branching strategy and branching best practices like naming conventions for specific development types. For example, using a prefix to indicate the type of development feature or bugfix
- Ensure proper use of scopes to decide who has access to each repository
- Make sure the review workflow includes which users have the final say in the review process and proper authorization to merge the changes.
A properly defined workflow describes the complete source code management cycle from creating new branches to making changes and, finally, merging the code to the master branch after review. This process helps organizations simplify the overall code management by pushing users to follow a specific workflow. This can also help easily onboard new developers.

Implement Proper Security Practices

This practice goes hand-in-hand with proper workflows, as security will be one of the primary considerations when defining the workflow. It should start from developer authentication and authorization, which controls who has access and what areas of the source code they have access to. Additionally, security practices should provide visibility into all the user activities with auditable trails to pinpoint any unusual activity in the source code.

Security practices coupled with a good backup and disaster recovery strategy are vital for the continuous operation of the development pipeline.

These best practices can help developers manage their source code securely and efficiently. A properly implemented source code management system will lead to fewer issues in the preceding stages of the pipeline and ensure smoother operation in the long run.
January 25, 2022
JFrog Extends Reach and Scope of CI/CD Platform

At its online JFrog swampUP Conference today, JFrog announced it has extended the reach of its ability to distribute software to include options based on peer-to-peer and content delivery network (CDN) mechanisms.

In addition, JFrog expanded the reach of the JFrog Pipelines continuous integration/continuous delivery (CI/CD) platform, enabling DevOps teams to build their own library of reusable pipeline steps via an Extensions Development Kit (EDK). DevOps teams can encapsulate frequent and common actions in their pipelines that can run sequentially or in parallel. That approach also serves to reduce the need to rely on plugin modules to extend a JFrog delivery pipeline.

Finally, JFrog has added another free public artifact center that provides a means to manage Helm charts, which are widely employed to deploy applications on Kubernetes clusters. ChartCenter is intended to make it easier to deploy microservices based on containers.

JFrog CEO Shlomi Ben Haim said all three additions to the JFrog portfolio extends the ability for users to manage the entire DevOps workflow from integration to delivery regardless of what type of software is being deployed or where it is installed.

As DevOps teams look to deploy software on edge computing platforms within an internet of things (IoT) environment, Ben Haim said they will need to be able to employ either a peer-to-peer or CDN-based approach to manage that process efficiently. Existing mechanisms are not designed to handle large volumes of artifacts that need to be delivered in a specific order. The new mechanism added to the JFrog CI/CD platform enables DevOps teams to achieve that goal without having to acquire a separate platform, he said.

In fact, Ben Haim noted, efficiently delivering software to edge computing platforms represents the next great leap forward for DevOps. Achieving that goal, however, will only be practical if the entire CI/CD workflow process keeps track of all the dependencies and metadata end-to-end, he said, noting that approach will enable endpoints to pull only the delta code required to update the software after an application is initially deployed.

There is no doubt extending best DevOps practices to edge computing platforms will be a major challenge. Most DevOps teams already struggle with CD because each platform software is being deployed on is unique. Because of a general lack of standardization in terms of potential endpoints that might be deployed at the edge, that “snowflake” issue is likely to become even more exacerbated as IT environments become more distributed than ever.

In general, Ben Haim said far too much of the DevOps focus continues to be on source code management when in reality the biggest issue IT organizations face is how to efficiently manage binaries. At a time when organizations are making massive investments in digital business transformation, Ben Haim noted the rate at which software is deployed and updated is about to accelerate dramatically.

As such, Ben Haim said it’s now only a matter of time before DevOps workflow processes will need to be able to scale well beyond their current limits.

June 24, 2020
Pulumi Tightens DevOps Platform Integration

Pulumi today released the 2.0 release of its open source platform for automating the provisioning of IT infrastructure in the cloud, providing tighter integration with a dozen different continuous integration/continuous delivery (CI/CD) platforms and source code management (SCM) systems. Via the latest update Pulumi also now includes CI/CD Apps, through which pull requests will trigger Pulumi previews and updates.

In addition, Pulumi has added tools to preview changes, while making it easier to share architectural patterns, libraries and best practices.

Finally, Pulumi 2.0 adds additional tools to enforce policies, simplify testing and manage secrets.

Pulumi is designed to enable developers to provision cloud infrastructure using familiar programming tools such as Python, JavaScript, TypeScript, Go and .NET/C#. That approach eliminates the need to master YAML files or other proprietary languages and templates.

Pulumi CEO Joe Duffy said the goal is to accelerate the rate at which management of IT is shifting left toward developers by providing them with the “superpowers” need to manage cloud infrastructure. Thus far, Pulumi claims to have more than 10,000 users of its tools.

In the wake of the economic downturn brought on by the COVID-19 pandemic, it is expected the rate at which control over IT has been shifting left will accelerate. As part of an effort to either contain or eliminate headcount, many organizations will reduce their reliance on IT operations staff by giving developers more direct control over IT infrastructure.

At the same time, however, Duffy noted that many IT operations personnel are finding it relatively simple to master Python, which they can then use to leverage Pulumi to automate the provisioning of large amounts of cloud infrastructure to become more efficient. Some organizations may prefer to retain IT operations staff that have learned how to program.

It remains to be seen to what degree tighter integration with CI/CD platforms might encourage developers to take more control over IT infrastructure. Support for the CI/CD platforms supported by Pulumi—Jenkins, Spinnaker and GitHub—will make it easier for developers to achieve that goal. Less clear is the degree to which developers want to take control over infrastructure. Regardless, many of them may soon have little choice in the matter.

Of course, Pulumi is not the only framework via which the provisioning of cloud infrastructure can be automated. It does, however, make it easier for developers to provision infrastructure without having to spend time learning the nuances of another set of programming tools. Even in organizations that do shrink the size of their IT staffs, there will still be pressure on developers to deliver more code faster. The amount of time developers may want to allocate to managing IT infrastructure is likely to be limited at best.

Whatever the path forward, many organizations will soon discover they can’t afford to wait any longer for their internal IT cultures to embrace best automation and DevOps practices. Economic pressure to optimize constrained IT resources are likely to become intense. No one may know for certain how long the downturn may last, but it is already apparent many organizations will be trying to do a lot more with less in the days ahead.

April 21, 2020
The Competitive Advantages of Modern SCMs

Source code management (SCM) is not a new concept. It has been in existence since around 1980, when Revision Control System (RCS), one of the first major SCMs, was released.

But that doesn’t mean SCM today is the same as it was decades ago. Modern SCM tools do much more than their predecessors. They handle not just application code, but all the configuration scripts and templates used to build and support the infrastructure that applications rely on.

Here is an explanation of what a modern SCM can do for you, and why it’s important from a business perspective to have a modern SCM.

What Do SCM Tools Do?

SCM tools, also known as version control systems (VCSs), at their most basic level, provide a history of all changes to one or more files and directories within a repository. These tools are most effective on text-based files such as source code and configuration files, as they can show line-by-line differences. While some tools can do specific binary file types (such as Microsoft Word documents), typically, binary files are stored intact, and each change results in a whole new copy being saved.

An example of what metadata is tracked in the history (CLI-based example):

$ p4 changes

Change 2 on 2019/04/19 by dev@desktop ‘deletion of library.dll’

Change 1 on 2019/04/18 by dev@jenkins ‘Initial commit’

…

You can display what has actually changed in each file (GUI-based example):

Distributed vs. Centralized SCM

There are actually three models of SCM tools: local-only, centralized and distributed.

There is currently no modern SCM tool that runs local-only. Modern SCMs have evolved beyond a local-only architecture.

Centralized SCM tools work by having every change committed directly back to the source server that is the authority for whatever is being worked on. There is code hosted on the local workstation, but any and all changes are tracked on the server. This model was dominant in the late 1980s and is still extremely popular in many large enterprises. The benefit of having everything centralized is all changes are tracked, and it is easy to stay in sync with the authoritative repository that leads to very few conflicting merges. The downside is a constant connection to the network is required to get any work done.

Distributed SCM tools came out of obscurity in the early 2000s with their biggest proponent: Linux kernel development. Linux kernel development had evolved into a globally dispersed team, and not all members had the bandwidth or always-on connectivity needed to continue to use their centralized SCM toolset. The biggest benefit of the distributed model is each workstation has a complete copy of the entire repository and can locally branch, tag, revert and commit changes. At certain points (often daily, sometimes weekly), each developer syncs their local repository with the remote repository (which can loosely be called the authoritative version). The biggest downside is a much higher likelihood of conflicting changes being applied to files in the repository if there isn’t a lot more coordination around the process. It isn’t enforced with locks like it is in a centralized model.

Why Use SCM Tools?

Reproducibility and traceability. Period. It really is that simple.

With SCM tools embedded in your development and support lifecycles, you can produce the code used for any version at any time, which will let you reproduce the binaries that were running in production. In addition, you can trace back to who actually changed the line of code that either fixed the defect or broke the world.

Let’s go through a few scenarios where this can make all the difference.

1. Fixing an ABEND from a Job that Only Runs Quarterly

It’s 3 a.m., and you receive a phone call from operators saying your job has ABENDed, and their normal remediation steps didn’t fix it.

Without SCM in place, you can only work with the code you have. You are in the middle of refactoring it, so it is in no shape to go anywhere near production–leading to meetings full of apologies and late nights spent working.

With SCM, you check the tags in the repository and pull the latest production build, fix it, test it, push it to production and have the job back up and running before others make it into the office. Then, you can create a new tag, and there is a record of what was done.

2. Discovery in a Lawsuit for an Event that’s Six Years Old

This is pretty straightforward. We live in a world where companies love to sue each other, and your legal team will appreciate your ability to reproduce things as they were so you can prove what does or doesn’t work as expected, or does or doesn’t include whatever patented code the other side claims. No one likes to lose a default judgement.

3. Client Finds a Bug in the Older Release They Still Run

This applies to managed offerings or when the client installs the software on their own; there is always that one client who for some reason can’t upgrade.

In this case, inside your SCM tool, as a best practice you would create a branch every time you do a release of your product. On that release branch, you can easily make code changes and rebuild and distribute the new, updated binaries of a version that was originally released two presidents ago, without having any impact on other customers or your own production deployments.

Timeline of Popular SCM Tools

There are dozens of version control tools and discussing the evolution of each one would fall far beyond the scope of this publication. However, there are a few key SCM tools that have led the way in establishing standards and norms for the industry. Their history is outlined here.

1. Unix

Concurrent Version System (CVS) was the first widely used SCM tool in the Unix ecosystem. It was a pioneer in the centralized approach when it was released in 1990. CVS is heavily based on RCS (to the point that most RCS repositories were seamlessly converted).

Microsoft had a tool called Visual Source Safe (VSS) that it supported and distributed from the mid-1990s through the early 2000s. VSS was good for the typical mid-sized source code repository. Microsoft did not use VSS internally, as their internal needs were too complicated and their code repositories were too large for the tool.

2. Cross-Platform SCMs: Perforce, ClearCase and SVN

Perforce was the dominant source management tool used within Microsoft for decades. Perforce supported the level of complexity Microsoft and other large enterprises had around tagging and branching. It was also cross-platform like other popular tools such as PVCS, which helped it support development across all facets of a large enterprise’s infrastructure, from mainframes to Unix to Linux to Windows.

Rational ClearCase (later bought by IBM) was heavily used by larger enterprises across all platforms, especially when mission-critical systems that leveraged big iron hardware and service-oriented architecture were involved. While ClearCase was a centralized system, it had several features that were unique and valuable to distributed teams, including dynamic views, which could be remotely mounted, and true code-level integration with Rational ClearQuest to track exactly what was changed in each defect and request. These concepts were revolutionary, but required large and reliable network interconnections, which is why distributed systems have become more commonplace today.

While enterprises were adopting PVCS, Perforce or ClearCase, many open source, web-scale and smaller organizations were adopting Subversion (SVN), released in 2000. It built on CVS’s success and specifically addressed a couple of major annoyances with CVS’s architecture, which included repository-wide versions (which allowed a more consistent approach to versioning applications), as well as atomic commits (meaning the entire change is applied at once—if any of it fails, then the entire change is rolled back).

Rational Team Concert, which emerged in 2008, represented another important point in the evolution of SCMs. It was cloud compatible and offered features (such as build management) that extended beyond just version control.

The Git Revolution

The world of SCM changed significantly with the introduction of Git, which was released in 2005.

Initially developed by the Linux kernel development team, Git built on the lessons learned from a previous product the team used, called BitKeeper. Git is a truly distributed SCM tool and is now the dominant SCM tool for all new development. Git is multi-platform and has the largest mindshare across organizations of all sizes.

Git has a much larger ecosystem around it than previous SCM tools enjoyed, and multiple vendors offer solutions that are built on it. Git is the default tool for most modern continuous integration tools, such as Jenkins.

Using Modern SCMs with z/OS

On the mainframe, SCMs developed in parallel to other platforms, but remained entirely separate in their implementation. Products such as Endevor, ChangeMan and ISPW were born as Library Managers, but were later used for version control. Still, the core technology that powers them is over 20 years old. They have remained substantially unchanged throughout their lives.

Recently, however, with the rise in popularity of of hybrid applications and the adoption of lean/agile development processes, the legacy SCMs have come under increasing pressure to modernize. The vendors who produce these products have belatedly tried to bolt on modern capabilities; and where this has been proven impossible or impractical, they have elected to integrate with Git. However, since Git is now fully supported on the z/OS platform, organizations requiring the capabilities of a modern SCM are able to use Git without the hindrance or cost of a legacy SCM.

You might think developers who work on legacy platforms such as mainframes, have to abandon their entire environments in favor of modern ones in order to take advantage of modern SCMs. Fortunately, that is not the case. Tools such as Dependency Based Build (DBB) bridge the divide between mainframe apps and modern SCMs. DBB lets mainframe developers use Git to manage source code for z/OS COBOL applications. It also supports Groovy for managing builds.

Git, and the build tools that integrate with it, have become the go-to SCM solution for virtually all developers today, on most platforms. With the rapid uptake of Git already on Z, and tools like DBB available, it is clear Git is also going to become the dominant SCM for the z/OS development.

As teams modernize their practices to handle the explosion in the sheer number of applications being built and the infrastructure automation scripts that support them, moving to an agile development methodology or trying to take advantage of DevOps practices such as continuous integration (CI) is impossible without a modern SCM tool to push all the changes through.

Modern SCM tools are the foundational building block every technology team needs to successfully support all aspects of an application’s lifecycle.

— Vince Power

September 3, 2019
Achieving Open and Integrated Development with IBM Z

“DevOps” and “mainframe” are not words you often hear in the same sentence. Yet, the reality is that even in our current age of DevOps, mainframes remain the mainstays of many companies’ IT infrastructure.

That’s why it’s critical for organizations to find ways to bring mainframe software delivery up to speed with modern DevOps practices, which emphasize collaboration, agility and continuous deployment of software to meet quality and time-to-market pressures. It’s also essential to be able to de-silo software delivery teams with a unified pipeline that includes common, modern source code management (SCM) and other tooling.

This is one area where the IBM Z Open Development environment can deliver real value. Built with the goal of supporting modern source code managers such as Git, IBM Z Open Development helps make a common DevOps pipeline, including mainframe teams, more practical through use of modern, open SCM, plus other essential features for developers.

Keep reading for details on how Z Open Development works and what it can do to make mainframes DevOps-friendly.

IBM Z Open Development: Making Developers’ Lives Easier

There is a looming shortage of mainframe developers as the current experts retire; according to BMC’s 2018 mainframe survey, staffing and skills shortage is the second top concern for the mainframe ecosystem. This is not an ideal situation for organizations that rely heavily on mainframes. To solve it, organizations must allow all developers to work on mainframe software, instead of relying on mainframe specialists.

With Z Open Development, developers are armed with the capabilities they need to integrate mainframe work with a common DevOps pipeline that employs a modern, shared SCM. They also have the ability to perform program analysis, edit, build and debug in a way that is similar to other development platforms.

Git is the de facto SCM for the open source community, and enterprises are also embracing Git as the standard SCM for distributed software delivery. Z Open Development makes key Git features such as full Isolation and true parallel development, a reality for mainframe development teams.

Traditional mainframe library managers don’t offer these features; hence, they don’t overcome the isolation that separates mainframe development from development for other platforms. Z Open Development tackles this problem by offering IBM Dependency Based Build and provides enterprises a standardized implementation of Git.

Essentially, Z Open Development is purpose-built IDE for developing and maintaining z/OS application components with a modern SCM that supports parallel development. It provides integrated development and build automation, which can be joined with a common DevOps pipeline. This provides a path to migrate traditional mainframe library managers to modern source code management systems such as Git and Rational Team Concert.

Key Features

Z Open Development is a neat and lean offering that can help development teams transform their software delivery around a common, automated delivery pipeline. Z developers can join a platform-neutral, continuous integration and deployment pipeline that is inclusive of z/OS. However, Z Open Development offers other attractive features that developers require:

1. Dependency-Based Build

IBM’s Dependency Based Build (DBB) allows clients to set up the build for COBOL, PL/I and other traditional z/OS languages just as they would other distributed languages through the use of modern scripting languages. By following the same model as distributed languages, and using standard scripting languages such as Groovy, the z/OS build can be easily added to the same CI/CD pipeline and managed by the same skills building the pipeline today. This ability to use the same CI/CD pipeline coordinator (such as Jenkins) removes the separation and allows for the creation of one coordinated pipeline. This includes being able to standardize on the approval flows, using the same quality gates and supporting the integration of the multiple parts of the application together.

DBB extends the Groovy language with an additional set of java APIs to allow access to run MVS, TSO and ISPF commands, as well as a facility to run existing JCL. DBB also provides a set of open source samples including a configuration-based build that can be used within your own organization, with minimal modifications.

With its GroovyZ capability, DBB also supports the ability to do automation in the pipeline for any additional configuration required. Since it’s Groovy, existing automation created for other platforms can easily be reused for z/OS.

2. Modern Editors

Developers can use modern editors for COBOL, JCL and PL/I to develop their applications. These editors are familiar and provide syntax highlighting and source code assistance to make coding a breeze.

3. Visual Program Analysis

Developers can check out the graphical views of the logical flow of any program they are working on for better program understanding. Developers can also access the graphical view of data flow within their program to identify different data elements and understand how they are populated and modified.

4. IBM z/OS Debugger

Z Open Development comes with the powerful Eclipse-based, source-level IBM z/OS debugger, which can be used to debug 24 and 31-bit z/OS applications written in COBOL and PL/I. Developers can modify variables during debugging while also being able to insert breakpoints during or prior to debugging. The visual debug capability provides developers with a graphical view of the execution flow through their program.

5. Simplified Integration

DBB integration with the editor enables developers to compile the programs using the same scripts defined for the pipeline build, which includes copying files with any dependencies to a specified host, running a build process and returning errors.

If the shared, modern SCM for the DevOps pipeline is Rational Team Concert (RTC), Z Open Development also offers RTC integration.

6. The Foundation for Z Open Unit Test

In addition to all of the above, Z Open Development lays the foundation for Z Open Unit Test, a unit testing tool for z/OS applications built on the Z Unit capability. Thus, Z Open Development allows developers to streamline and automate not just their SCM process, but also unit testing. Note that the Z Unit capability is also offered in IBM Developer for z Systems.

Empowering the Endangered

DevOps is based on the idea of eliminating silos to have a more collaborative approach to application development for more efficient and predictable output.

Mainframes have long been isolated, which places them in opposition to the fundamentals of DevOps. Z Open Development arms developers with the capabilities they need to build and maintain mission-critical software while still leveraging a shared DevOps pipeline that includes Git and Jenkins. It offers an easy first step to DevOps adoption and equips DevOps teams with the power to develop mainframe applications with familiar, shared skills and tools.

— Twain Taylor

August 23, 2019