Parallel development with Nuve

What is Nuve?

Nuve is an automation platform designed to simplify SAP infrastructure for developers. Traditionally, SAP developers lacked the convenience of a local development environment, a standard benefit for most modern developers. Nuve addresses this by enabling developers to effortlessly set up SAP systems with data through a few clicks. This innovation narrows the gap between traditional SAP development and modern practices. It empowers ABAP developers to:

Develop independently in isolation.
Benefit from rapid iteration cycles.
Experiment safely without risk to others.
Effectively implement branching strategies.

Nuve solves object locks

In traditional central SAP landscapes, developers are required to share the same system. This has been the norm largely because setting up a new SAP system was a complex and time-consuming task. However, Nuve changes this with its advanced automation capabilities. Now, creating a new SAP system for development outside of the central landscape can be accomplished in just a few minutes. This breakthrough allows each developer to have their own isolated system, mirroring the experience of a local development environment. It effectively resolves the common issue of object locks in shared systems, enabling more efficient and independent development workflows.

Nuve enables seamless production hotfixes

SAP ABAP developers often face significant challenges when a production issue arises in project work. This situation often requires stoping ongoing development, implementing a fix, and then redoing the interrupted work, which can be highly inefficient. In contrast, modern developers have largely overcome this inefficiency by adopting branching strategies. These strategies usually involve the use of Git and platforms like GitHub, alongside tools like abapGit within SAP.

Nuve enhances this process by providing isolated development environments. This integration not only facilitates the adoption of branching strategies in SAP development but also puts SAP developers on par with their counterparts using modern development stacks. It streamlines the process of managing code changes and fixing issues without disrupting the main development flow.

Branching and abapGit Flow

The shift from a centralized to a distributed version control system allows multiple developers to work on the same codebase simultaneously through branching, where each branch serves as isolated code changes for features, bug fixes, or experiments. This independence is a significant change from the exclusive object checkout in traditional ABAP.

Several workflow models have been developed to effectively use Git, catering to different project sizes, team structures, and development practices. The recommended workflow for use in SAP ERP systems is abapGit flow, which is very similar to GitHub Flow, a simplified workflow ideal for projects that deploy frequently. abapGit flow begins with creating a new branch, making changes, and opening a pull request. The code is then moved into the central SAP landscape and tested. Once the code is confirmed ready for production the pull request is approved and a transport is released. It's recommended that pull requests are moved into the central SAP landscape sequentially, so that changes are as incremental as possible and the source to any failed tests are easily identifiable.

To realize Continuous Integration (CI), or trunk-based development, which advocates for brief branch lifespans and daily integrations with the main branch, a robust foundation in branching and a proper workflow is essential. This ensures that developers consistently work with the most up-to-date code.

An overview of abapGit

abapGit is an open-source tool for managing ABAP source code in Git. It's designed for the ABAP development environment in SAP systems, facilitating version control and collaboration.

Key features:

Git Integration: Enables ABAP code to be stored in Git repositories, allowing for version control similar to modern programming languages.
Collaboration: Simplifies collaborative development, code sharing, and reviewing.
Change Tracking: Tracks changes in ABAP code, supporting better audit trails and historical analysis.

Usage:

Install: abapGit is installed directly in the central SAP landscape development (DEV) system.
Repository Management: Developers can clone, pull, and push ABAP code between the central SAP landscape DEV system and Git repositories or this can be automated and integrated with change management tools.

Benefits:

Brings modern source code management practices to ABAP.
Enhances team collaboration with code reviews
Enhances code quality by enabling ABAP style guides
Facilitates continuous integration and development processes.

Redundancy

While abapGit facilitates a modern, Git-based approach to SAP development, it does not prohibit the use of legacy SAP development practices. Transitioning to a Git-centric workflow is recommended to maximize organizational benefits. However, there may be situations where reverting to legacy workflows or adopting a dual workflow approach is necessary, especially during the transition to modern practices.

Limitations

abapGit does not yet support a small number of less common SAP object types. Support for these objects can be added as needed. In scenarios where unsupported objects are critical, a dual workflow approach may be utilized. Prioritized support is available to fast-track the integration of specific object types into abapGit.

Enterprise support

Enterprise-level support for abapGit is offered both by its creator and the Nuve team. Additionally, a robust community support network is available, providing a wealth of resources and assistance.

Package structure

In SAP software development, logical packaging is essential for system maintainability and team collaboration. It ensures that related objects are organized, which simplifies updates, troubleshooting, and understanding of the system's structure. Furthermore, each Git repository corresponds to a single SAP package, this organization is vital for effective version control and change management.

Workstream approach to packages

Adopting a workstream approach to creating SAP packages involves organizing packages based on distinct streams of work or project segments. This method can be particularly effective in large projects or in organizations where multiple teams work on different aspects of the system. Here's how it works:

Define workstreams: Identify distinct areas of work or project segments, such as finance, sales, HR, etc.
Create dedicated packages: For each workstream, create a dedicated SAP package. This ensures that all developments related to a specific workstream are grouped together.
Enhance collaboration: This approach can improve collaboration and clarity, as team members can focus on packages relevant to their workstream.
Manage dependencies: Identify packages that contain dependencies affecting multiple workstreams. For instance, consider a scenario where there is a shared utility package utilized by several teams. It's important to recognize and manage these kinds of dependencies to ensure seamless collaboration and minimize conflicts across different workstreams.
Consistent standards: Apply consistent naming and development standards across all workstreams to maintain uniformity and ease of understanding.

Transitioning from a monotlithic package

This phased and structured approach helps ensure a smooth transition with minimal impact on ongoing operations.

Define logical groupings: Best practice is the workstream approach to package groupings. However, some organizations may want alternative logical groupings for the objects. This could be based on functionality or other relevant criteria.
Create new packages: Create new packages according to the defined groupings.
Migrate objects: Gradually migrate objects from the monolithic package to the new, logically grouped packages. This should be done in a controlled manner to minimize disruption. In most cases, start with a single package and ensure that the process and groupings are appropriate for your organization.
Test and validate: After each migration, thoroughly test to ensure that the moved objects function correctly in their new package.
Update documentation and training: Update any relevant documentation and provide training or briefings to the team to familiarize them with the new structure.
Continuous monitoring and adjustment: Monitor the new setup for any issues or inefficiencies and adjust as needed.

gCTS in S/4HANA: benefits and considerations

gCTS, standing for Git-enabled Change and Transport System, is an advanced version of the traditional SAP Change and Transport System (CTS), introduced in SAP S/4HANA 1909. It integrates CTS with Git repositories, enabling better version control and collaborative development within SAP environments. This enhancement focuses on providing SAP-specific integrations, particularly in transport management. This facilitates a smoother transition for developers who are accustomed to working within SAP's framework, by combining traditional SAP transport management with the modern capabilities of Git.

Integration with SAP transports: gCTS's tight integration with SAP transports is a significant advantage for those working within the SAP ecosystem.
SAP-specific focus: While this SAP-specific approach aids in developer adoption within the SAP framework, it also presents a limitation in broader development contexts.

Why chose abapGit over gCTS?

Industry shift: The software development industry is evolving towards more modern practices, including SAP Business Technology Platform (BTP) which integrates Git-based development workflows.
Universality of Git: General-purpose Git is a versatile version control system widely used across various programming environments, not limited to ABAP.
Future-readiness: As SAP developers increasingly engage with SAP BTP, understanding and utilizing general-purpose Git will become essential.
Lagging progress: The development of SAP's gCTS is not progressing as rapidly as the broader Git community's advancements. We have observed that gCTS still lacks features that are available with abapGit. Additionally, gCTS is notably absent in ECC environments.
Recommendation: Given these developments, transitioning towards a general-purpose Git approach is recommended for broader adaptability and future readiness in diverse development scenarios.

Central SAP landscape implications

Easy setup of abapGit in DEV system only

abapGit is installed directly in the central SAP landscape development (DEV) system. The setup typically takes about 15 minutes and only impacts the DEV environment with a small footprint.

Creating the abapGit report in DEV: This process requires a developer to create a report (recommended name of ZABAPGIT_STANDALONE) via SE38 that includes the abapGit latest build (abapGit) of the standalone version. Since abapGit will only be available in DEV, you can save it to a local package (recommended to use $ABAPGIT_STANDALONE) without the need to create a transport.
Git client certificates installation: You also need to install the Git server's SSL certificates you are using, such as those from GitHub (see abapGit SSL Setup).
abapGit developer edition: The final step in the process is to use the standalone version of abapGit to install its developer version. Similar to the standalone version, the developer version will also be installed in DEV only, so it's best practice to use the package $ABAPGIT during the installation process. For more details, refer to the official abapGit documentation (Installing abapGit).
Uninstallation instructions: Uninstalling abapGit developer edition is also very straightforward and can be done directly via the standalone version. If you decide to uninstall the standalone version of abapGit, you should delete the report ZABAPGIT_STANDALONE and also remove any associated Git SSL certificates.

Fewer transports is better

Developers often need data. However, most DEV systems contain little to no data. As a result, they move code via transports from DEV to QAS to complete their work. This has two obvious drawbacks that directly impact the developer:

The number of transports is artificially higher than what is needed
The cycles of code, test, debug, repeat become significantly longer

A higher number of transports increases the risk to the system as development is often spread across various objects, and it is crucial to ensure that all transports are included and the sequence is correct. With high-quality data in the instance where the developer does their development, the number of transports required per feature should decrease to 1-2. For developers at most organizations, this represents up to an 80% reduction in the number of transports.

Moving code from Nuve to central DEV

There is a paradigm shift when Git becomes the source code repository. In a parallel development environment devs are pushing and pulling the main branch then creating branches to implement their changes. The role of DEV in the central landscape begins to get smaller and serves only as an environment to copy branches to transports and promote those transports to QAS for user testing.

Nuve to central DEV

The diagram depicts the workflow for distributed development, within the context of Nuve and the central SAP landscape. Here's a step-by-step breakdown of what's happening:

Development in isolated environments: Developer A or a team of Developers B are working in Nuve isolated environments. Nuve allows them to work independently without affecting each other's work.
Dev integration with Git: The work from these Nuve environments is then integrated into a version control system, typically GitHub. Code changes from the developers are committed and pushed to corresponding branches in a shared repository. Once the developer believes the code is ready, they open a pull request (PR) for the working branch.
Transfer to central SAP landscape - DEV: When the PR is opened, the code from the branch is pulled into the DEV system and added to a transport request (TR). Then a transport of copies (TOC) is created, released, and promoted to QAS.
Quality Assurance in QAS: The code undergoes user testing in QAS. If the tester approves the change, the TR in DEV is released to QAS before being promoted to production (PRD). If the tester rejects the PR, changes are reverted on the TR in DEV, a TOC is created, released, and promoted to QAS. Now QAS is back in sync with PRD and open for a new PR/TOC.
Continuous Feedback: If a PR is rejected, it is changed to draft mode on GitHub, and the tester provides feedback to the developer on the reason for the rejection, allowing them to make iterative improvements to the code.
Deployment to PRD: Finally, the code that has passed testing in QAS is queued to be deployed to PRD using the TR that was created in step 3.

System & cost optimization strategies

Given how easy it is to create ad-hoc isolated systems with data via the Nuve self-service portal, it is recommended to shut down or delete any sandbox or project systems that are not currently in use. For most organizations, this translates into substantial savings. Should there be a need for additional isolated systems, you can readily leverage Nuve Platform.

Transition to Git-based development in SAP environments

This modern approach also means that developers no longer have to deal with transports in the traditional sense. While a basic understanding of CTS is still important, moving toward a Git-based approach means that developers can shift their focus from thinking in terms of transports to thinking in terms of commits, branches, and pull requests. Within a Nuve system, developers work on local packages and focus on commits, which are small, discrete changes to the code base that are part of a branch. A branch is essentially a collection of changes, which can be thought of as one or more objects. From an SAP perspective, this can be considered as the equivalent of a transport request.

Deployment with Git

In legacy developement, CTS is used to manage the migration of changes between different systems, such as from DEV to QAS and finally to PRD. When moving towards a Git-based approach, the process of handling changes adapts to fit a more decentralized model of version control, yet still must interface with the SAP transport system for the actual deployment to QAS and PRD. Here's how commits, branches, and pull requests can be integrated into this process:

Commits: A commit in Git represents a single point in the history of a branch and contains the changes made to one or more files. In the SAP context, multiple commits are bundled together in a branch to form a cohesive change or feature update, or to implement a fix.
Branches: In Git, a branch allows developers to diverge from the main line of development and work independently. Once a feature or a fix in a branch is complete, it's merged into the main branch, which would be aligned with the production code in the SAP system. The completed work from a branch would then be associated with a TR when it’s time to move the changes to QAS and PRD.
Pull Requests: A pull request in Git is a request to merge the changes from one branch to another, and it's also a place for code review and discussion. In SAP, the approval of a PR would typically be the point at which a TR is released to move the changes to the next system. The PR ensures that the code is reviewed and approved before being introduced to the more stable environments like QAS and PRD.

Managing merge conflicts in Git

In Git, when multiple developers modify the same parts of an object and attempt to merge their branches, conflicts are flagged for resolution. Developers must then manually resolve these conflicts, choosing which changes to keep, alter, or combine, often with the aid of Git's mergetool. After resolving these conflicts and merging the changes, a peer review process is typically conducted through pull requests to validate the accuracy of the merged code and ensure it introduces no new issues.

Nuve instance deployment options

Embrace the public cloud advantage

The public cloud presents a strategic opportunity for organizations to enhance operational efficiency. It is underpinned by a pay-as-you-go model, minimizing the need for upfront hardware investments and the ongoing costs of infrastructure maintenance. Rapid deployment capabilities mean SAP instances are readily available, allowing businesses to pivot their focus towards their core operations. Furthermore, adherence to comprehensive compliance and security standards by leading public cloud providers supports the fulfillment of regulatory obligations.

Tailored excellence with private cloud

For enterprises seeking a more personalized cloud solution, our platform seamlessly integrates with top-tier cloud service providers such as Google Cloud Platform (GCP), Amazon Web Services (AWS), and Microsoft Azure, ensuring compatibility for hosting SAP instances. A private cloud brings the advantage of enhanced security, granting peace of mind through dedicated infrastructure exclusive to your organization, essential for handling sensitive or regulated data. It offers unmatched customization and control, enabling an environment configured to specific business needs and compliance requirements. The implementation of custom security policies is streamlined, bolstered by the benefits of a private network, which maximizes security.

Data management options for system creation

When setting up systems for parallel development, a common strategy is to use a database copy. The process typically involves selecting a base system, often a Quality Assurance (QAS) or a sandbox (SBX) environment. We offer flexibility in transferring the file to our Nuve team for integration. The usual steps are as follows:

Virtual machine setup: Establish a virtual machine (VM) of the right size in the cloud.
Configuration for secure transfer: Configure the VM with Secure Copy Protocol (SCP). Alternative options such as gsutil or the Google Storage Transfer Service can be utilized on a case-by-case basis depending on data sizing and customer infrastructure.
Database transfer: The customer transfers a database backup to the VM using an appropriate method.
SAP system preparation by Nuve: Our team readies the shell SAP system. This includes setting up firewall rules to block both inbound and outbound traffic and installing all necessary dependencies.
System copy execution: Nuve performs the system copy using the provided database backup.
Post-copy configuration: Nuve handles the configuration of Remote Function Call (RFC) settings, disables email functionalities, and establishes any required interface connections.
Backup and rapid deployment: The final system is saved as a backup on the Nuve Platform. This allows for quick deployment of instances or entire system landscapes in a matter of minutes.

Subsequent environment configurations are automated

A large majority of the manual effort involves preparation and post-copy steps, both of which can be automated. This is feasible because we track all changes from the initial manual configuration. In SAP, nearly all data is stored in tables. With abapGit, you can save entries from any of these tables. By leveraging abapGit, we automate the setup process, thereby making it more consistent, faster, and repeatable.

Data limitations

We can handle as much data and system size as our hosting hyperscalers allow. So, whether you're on AWS, Google Cloud, or Azure, you're only limited by what those platforms can handle.

Opportunity for data reduction

Reducing database size is crucial for enhancing performance and cutting costs in the Nuve environment. Consider these strategies:

Data archiving (recommended): Archive old or irrelevant data before initiating the database copy. This step significantly reduces the amount of data needing transfer and storage.
Selective data copy: Opt for copying only essential data rather than a full database copy. For instance, prioritize the most recent data or information directly relevant to specific tests or development activities.
Data deletion: Proactively identify and remove unnecessary data, like outdated logs, temporary files, and obsolete reports.
Lean data sets: Employ lean and representative datasets, tailored to fulfill testing and development requirements without excess bulk.
Database partitioning: Implement partitioning for large tables to streamline data management and transfer processes, making them more efficient.

Improved "refresh" process

Once a system or landscape is configured on the Nuve Platform, you can easily revert back to a previous state with just a few clicks. This significantly enhances the development, testing, and experimentation experience, as you can quickly refresh system data. This process offers numerous benefits for developers and testing, along with other use cases. Additionally, it means that your QAS system will maintain better data integrity for longer, since it is not being used as a development system by users.

Risk-free archiving with Nuve

The concept of archiving can often appear daunting, with perceived risks balanced against its value, and potential for business disruption. To mitigate these concerns, some customers choose to set up their system on Nuve Platform without archiving. Then, utilizing the Nuve refresh process, they can safely test and fine-tune their archiving procedures. This approach enables them to develop an archiving process that is both effective and well-suited to their organization's needs.

Hyperscaler Configurations

The infrastructure built by Nuve can be created on a variety of providers, but the following are steps specific for organizations chosing a private cloud on Google Cloud Platform (GCP):

Create a dedicated GCP project and enable the Compute Engine api.
Create a Service Account with the proper permissions to conduct compute tasks.
Create and download the Service Account Key to enable Nuve to access your GCP project.
Store the Service Account Key in Secret Manager.
Add authorized Nuve Employee as a principal to the Service Account Key secret in order to encrypt the key.

Role-Based Access Control and Least Principle Privilege are used to minimize the risk of unauthorized access or changes to critical systems, but enabling audit logs for all activities within the GCP project is encouraged.

Google Cloud VPC

By opting for a private cloud option in GCP's Virtual Private Cloud (VPC), you gain access to a secure, isolated section of the cloud. This isolation provides enhanced security and gives you complete control over access to your computing environment. The VPC's customizable network configuration, including IP addresses, subnets, route tables, and gateways, allows you to tailor your network to meet specific needs. Its global networking capabilities facilitate seamless communication across resources in different regions without the need for separate networks.

Secure VPN access

GCP's VPC provides a range of interconnectivity options, including Cloud VPN and Cloud Interconnect, to ensure secure and high-performance connections between your VPC and on-premises infrastructure. Both options are effective for establishing connections with on-premises networks.

Commonly open ports for SAP instances

3200: SAP GUI - Standard port for SAP GUI connections.
3300: Eclipse ADT - Used for Eclipse-based ABAP Development Tools (ADT).
44300: Secure Fiori Access - Typically accessed via a proxy for secure connections to SAP Fiori applications.

Note: Additional ports can be configured based on specific needs and requirements.