At Nuve, we use Vercel for our frontend development. Each developer works on a separate branch. When they open a pull request from the branch, it automatically becomes a "preview"—an isolated cloud-hosted version of the frontend for testing. If everything looks good, we merge it into the main branch, which triggers an automated production deploy.

This approach to development is very flexible because it lets you test changes in isolation. That's a big deal. If something breaks, you can be almost certain it's because of the change you just made. This stands in stark contrast to SAP's shared environments, where it's tough to pin down whether a bug came from your change or one of the potentially hundreds of other users working in the same system.

SAP is a different beast

While it's true that SAP systems are usually much bigger than typical web development projects, that doesn't mean you can't borrow some good practices from the modern dev world. Sure, the scale and complexity bring unique challenges, but you can often find workarounds or make some compromises to achieve similar outcomes. And let's not forget that SAP has its own set of interdependencies, making it even more crucial to have isolated testing environments.

A quick look at modern development practices

In most development settings outside of SAP, the code is usually separated from the database. What that means is your code resides in files, not locked away in a database. This setup makes it easier to work offline or with a lightweight database version, allowing each developer the convenience of coding straight from their laptop.

Local development for SAP: It's all about compromise

When you decouple code and configuration from data, it is very easy to run a local development environment. Each developer can work in their own system, avoiding classic SAP headaches like object locks, insufficient test data, and the need to move code prematurely to QAS for testing. Not to mention avoiding conflicts with other devs and the fear of being the one to break the system for everyone.

Standard SAP code and config is not file based, however, it can be. abapGit allows us to decouple the code and config from the data, allowing local development to happen with any source-code editor. This setup lacks a database, but in a lot of cases, you don't need one. If you use Visual Studio Code for SAP development, you can install the abaplint app to get similar features to SE80 or ADT like semantic highlighting, pretty print, etc. This is a low-cost approach but lacks real data, a compromise.

If you want a full SAP system with the database included, the system requirements are too high to run on a laptop, making the traditional local setup unfeasible. However, using Nuve automation and cloud infrastructure, we can create isolated environments for each developer. Although this isn't quite the same as a local setup, it's a close approximation that works with the constraints of SAP's architecture. It allows developers to create personal development systems and use branches. The compromise here is additional costs. But the good news is that with Nuve's intelligent automation features, managing these costs becomes surprisingly easy. The secret sauce is these systems are sized appropriately for development and very short-lived, typically only on for a few hours per day. The benefit is higher productivity and an improved developer experience.

Stay in the loop! Subscribe now for the latest updates. 📩

Subscribe

Automated testing for high-quality code

Automated testing is a big deal in modern development. Let's say you get tasked with a new feature request. First, you pull the main branch, create a new branch for your changes, and then run the automated tests to ensure everything's working well. If any of the old tests fail, it's a red flag that your changes broke something. That failure is helpful because it points you to exactly where you need to debug.

Once you've sorted out the issues and all the tests are passing, you're good to go. Your changes are ready for whatever comes next. Speaking of which, what does come next?

Two paths to quality assurance with branches

Standalone QAS environments: The SAP equivalent of a preview

Just like how we use previews in our frontend work at Nuve to test changes in isolation, it's possible to automate creating a standalone QAS SAP instance that includes the branch being tested. It's your own personal "preview" in the SAP world. This setup helps you avoid all those common headaches—bad data quality, clashing with other ongoing projects, and the mess of rolling back faulty code. When you pair this with automated testing, you can be confident that your code is ready for production. And if it turns out the business doesn't want that change, just delete the preview instance.

Centralized testing in complex SAP landscapes

When you're dealing with a multifaceted SAP system, sometimes there's no getting around testing in a centralized landscape. Maybe it's because you need accurate input from external systems, like a cloud tax calculation engine or an e-commerce platform. Here's where Nuve's automation features really come into play, working alongside SAP's Change and Transport System (CTS).

Here's how it works:

1. You make your change on a Nuve system, create a pull request, and kick off a workflow that runs through a battery of quality checks, like static analysis and automated testing.
2. If everything looks good and it passes peer review, your code is pulled into the SAP dev system and added to an automatically created transport request (TR).
3. This code then gets copied into a transport of copies (TOC), which is automatically moved to the Quality Assurance System (QAS).
4. At this stage, users test your changes in this centralized QAS. If the change meets their requirements, they approve the pull request.
5. This triggers the last bit of automated magic: the TR is released, automatically moves to QAS, and is queued up for production. The move to production follows whatever process you use today.

Need revisions after step 4? Just repeat the steps, using the same branch. The workflow restarts, skipping creating a new TR since one already exists. A new TOC is still created and automatically moved to QAS with the revised code.

What if the change is scrapped? Close the pull request. This triggers a workflow to back out the changes in both DEV and QAS by pulling the main branch into the DEV system. A new TOC is still created and automatically moved to QAS. Last, the TR is deleted so that it never moves up the landscape, as it doesn't need to since DEV and QAS are back in sync with PRD. Of course, there are exceptions where this requires human intervention but the workflow will notify you.

Key takeaways

The branching strategy includes many steps, but most of them are automated. This process leads to cleaner code, fewer headaches, happier devs, and a more competitive and agile business.