The short answer to 'when should you use abapGit with Nuve?' is: always. However, there are certain exceptions where backups might better serve our development workflows. Before diving into the specifics of when to opt for abapGit versus backups, let's first explore the advantages of abapGit and then address its limitations.

## Why are many developers using abapGit?
### Modern developers rely on Git
It's no secret that in today's development landscape, Git is the best practice for source code management. It's the go-to for version control, collaboration, and tracking changes. 

If you're not using Git, you're missing out on a world of streamlined development processes. As a developer, you should continuously keep up with modern tools that make our job easier and improve code quality. abapGit allows you to use Git in SAP systems in conjunction with a Git platform like [GitHub](https://github.com/).

### File-based flexibility
One of the standout features of abapGit is that it's [file-based](https://docs.abapgit.org/user-guide/reference/folders-filenames.html#special-cases). This means your code is saved to files as opposed to being stored in the database. 

The result is that there's no need to persist the SAP instance to save your code, instead, you simply commit the code to GitHub. This offers a level of flexibility and ease that's hard to match. It's a perfect complement to the short-lived SAP instances of Nuve Platform. 

### Fostering creativity and efficiency
With abapGit, handling features, experiments, and bug fixes is much easier. It encourages developers to innovate without the fear of breaking the main codebase. 

You can start a new branch to experiment with a feature. If it doesn't work, you can delete the branch and revert to the original code. However, if the feature works as intended, open a Pull Request. After all checks pass, merge it with the main branch.

### Seamless integration with CI/CD
Continuous Integration and Continuous Deployment (CI/CD) have become staples in modern development. abapGit enables you to integrate your development and deployment processes with tools for CI/CD pipelines, such as [GitHub Actions](https://docs.github.com/en/actions/learn-github-actions/understanding-github-actions).

Setting up GitHub Actions is straightforward. Just add a configuration file. Then, every time you commit code to GitHub, it will activate workflow checks based on your settings.

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

## What are the limitations with abapGit?
### The abapGit community is active and supportive.
The beauty of abapGit is its wide-ranging compatibility with nearly all objects. While there are a few [exceptions it doesn't support yet](https://docs.abapgit.org/user-guide/reference/supported.html), the key point is "yet".

The community spirit is alive and well with abapGit. If you stumble upon an object that's not available, don't hesitate to [flag it in the issue list](https://github.com/abapGit/abapGit/issues/5912). Even better? Roll up your sleeves and contribute to making abapGit even more comprehensive.

### Config as table data
Some people think abapGit can't handle config. This is not correct. 

Config is essentially table data, and you can indeed save it to abapGit. However, if you've made significant configuration changes, taking a backup might be more convenient.

> ### 💡 Pro tip
> If you're scratching your head unsure about which tables to use, here's a little hack.
> First, save to transport. This lets you identify the tables to add to abapGit. 

## When should I use backups?
### Created significant test data
If you have significant test data, for example if you generated SFLIGHT data, it's backup time. While abapGit can handle table data, it doesn't make sense to add thousands of table entries to Git when you have the option to take a backup. 

### Using objects that abapGit doesn't yet support
When using objects that abapGit doesn't currently support, a good workaround is to take a backup. This approach lets you continue working on your project while waiting for the abapGit developer community to add support for that specific object.

### Performing multiple manual steps
A handy rule of thumb? If you're repeatedly going through several manual steps, consider it a cue to take a backup. 

Let's say you have to add three different repositories every time you create a new instance. Rather than repeating this process continuously, do it once, create a backup, and just like that – you've got a ready-to-use starting point.

## Key takeaways
As the world of SAP development evolves, tools like abapGit are leading the charge in fostering efficiency, collaboration, and innovation. Dive in, explore, and let abapGit elevate your development journey!

Happy ABAPing!

A best practice guide on when to use each.

Understand the pros and cons of using abapGit and backups in SAP development on Nuve. Make informed decisions on when to leverage each option for optimal efficiency.

Choosing between abapGit and backups

Managing costs, particularly across complex system landscapes with hundreds of SAP systems is a challenging and daunting task. You need to balance the needs of the business while ensuring that you keep costs under control.

Traditional SAP development, test, and project environments can be very expensive, especially when you factor in hardware costs and the person-hours needed to provision and maintain everything. It can easily become a burden on any business. Smaller businesses typically need to outsource the management to a third party Basis provider and larger businesses need dedicated teams to help maintain their complex landscapes.

## Traditional Basis
For nearly as long as SAP has existed, on-prem systems were managed by purchasing hardware and having an in house team manually deploy and maintain systems. This typically required Basis teams to be responsible for end-to-end management of the infrastructure. Infrastructure management is a laborious task. Any Basis admin worth their salt knows this. They typically create documentation that spans hundreds of pages to allow them to repeat routine tasks such as system refreshes or copies. Given the effort level to provision systems, typically, once systems are up, they are left running forever.

In recent years, there's been a move from on-prem to cloud hosted systems to try to reduce costs. While in general, this is a good direction, it's only part of the solution. This is because cloud infrastructure is meant to scale, but in practice, SAP systems rarely do.

## Automate your savings
There are two main areas where automation can help substantially reduce costs, decreasing the always-on nature of SAP systems and eliminating the need for person-hours for routine tasks.

There's significant friction between the product or project teams that need systems and the Basis team that can provision those systems. Typically, a request must be put in and approved, and then Basis manually creates the system. Once it's up, unless [something goes wrong with the system](/blog/sap-abap-fails), they often forget about it.

### Self-service system provisioning
A self-service portal can eliminate the friction, allowing project teams to create a system with a single click. This is a huge first step in bridging the gap and speeding up the process. 

### Self-service system scheduling
Going beyond that, the team should have the ability—perhaps even be required—to set a schedule for when the system is running. After all, it's unlikely to be needed 24/7. For a global team, the system can likely be shut down on weekends.

Since it's self-service, the team can easily modify the system schedule. They can even start the system if it's needed while it's shut down. Once the system is no longer needed, they just delete it.

### Self-service system backups
Wondering what happens if you delete it too soon? No worries. Disk storage is affordable, they can take a backup before deleting. Should the need arise to resurrect the system, it's easy to provision it from where they left off.

## Let people focus on value-added work
All of these strategies above rely on automation. This means that one of the largest expenses, person-hours, is mitigated with this approach. That allows those same resources to focus on more value-added, complex work, such as ensuring that productive environments are stable, protecting against cyber threats, and supporting with tasks that require a more nuanced human touch.

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

## Real life example
Consider that the average month has a total 730 hours (365 days x 24 hours/day / 12 months). It also has an average of 174 work hours (365 days x 5/7 work days/week x 8 work hours/day / 12 months). That means you only need a system running for about 24% of the time (174/730).

Now, you might be thinking, but what if our users need the system during off hours. Why not empower users to simply start the system if they need to use it during off hours? The savings across dozens of project systems are substantial.

This scenario should work for most projects but assuming you have a unique requirement where this is not possible, you can still have considerable savings by automating the creation of the system and ensuring it is deleted when the project is complete, as opposed to the status quo, where Basis resources spend a few days creating it and then the business forgets about it after the project ends.

> ## Run ABAP Platform on Nuve for just $9/month
> Want an affordable way to get the ABAP Platform trial up and running? Starting at just $9/month, Nuve makes it super easy and cost-effective. Here's why you'll love us: 
> 🌍 Always accessible: Access your system from any device, any time. 
> 🔒 Secure: Enjoy peace of mind with HTTPS Fiori access. 
> 💾 Hassle-free backups: Effortlessly save and restore your progress. 
> 🛠️ Ready to roll: Get coding faster with pre-configured abapGit. 
> **[Join the beta →](/pricing/personal#join-beta)**

## The bottom line
This type of automation is being used by leading companies today. Many SAP customers and partners are taking advantage of the rewards of cloud-based automated system deployment and management. If you're interested in learning how you can be a savings hero at your company, or simply want to learn more about strategies like this and others to save on costs, [contact us today](https://www.nuveplatform.com/contact).

Unlocking the secret to more efficient system budgeting

Unlock the secrets to efficient budgeting through smart automation that slashes both costs and labor.

Smart automation, smarter cost management

We've all been there. That feeling of fear and dread sets in the moment you realize something is wrong—and you caused it. A thousand thoughts race through your mind: Why hadn't I been more careful? Why hadn't I double-checked my code before executing it? You're instantly filled with regret and self-loathing.

Even the most seasoned ABAP devs have, at one point or another, caused a problem or even brought down SAP systems. You're not alone.

## The nature of shared environments
SAP development typically happens on shared environments, where developers and functional resources are simultaneously making changes. This means that any error you make impacts everyone else using that environment. And it's tough to undo changes within SAP. Sometimes, it's even impossible. Fixing the issue usually requires a coordinated, company-wide effort, often involving Basis to manually resolve the problem. This could range from a simple rollback to a full system restore.

## The ripple effect in a shared environment
Reasons for bringing down the system can vary, but the culprit is often due to a few core shortcomings in SAP development: a lack of automated testing, the absence or difficulty of peer reviews, insufficient test data, and shared environments. In contrast, modern development outside of SAP relies on local development, allowing for risk-free testing with no impact on others.

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

## Real-life stories from SAP devs

### It happened to Lars
It's not just "newbies" or "freshers" - even the best of us have faced those heart-stopping moments. Take renowned SAP developer **Lars Hvam Petersen**, creator of [abapGit](https://abapgit.org/). Lars had his heart pounding one fateful day when he was performing a seemingly simple database table conversion. What started as a mundane task turned into a disaster as he impulsively killed the session at the most inopportune time. Suddenly, he felt his stomach drop. The database table was now filled with inconsistencies, causing a cascade of short dumps across the system. It was like watching a train wreck in slow motion. He had to work closely with a DB admin, who was initially puzzled and slightly annoyed, to make some intricate changes just to sync the database and SAP app server. Lars was haunted by what could've been an irreversible catastrophe. Even today, the memory is etched into his mind like a permanent scar.

### It happens to all of us
My story isn't any less harrowing. I was implementing an SAP note, thinking it would be a walk in the park. But as I worked through the process, dependency after dependency started showing up in the fine print, the nightmare unfolded. Soon, the development environment started spitting out system short dumps left and right. My inbox filled with urgent messages and my phone wouldn't stop buzzing. The Basis team had to drop everything to restore stability, and the tension was palpable. I could feel my colleagues' frustrations growing, though they left them unsaid. That day, I kept replaying the sequence of events over and over in my head, haunted by my careless oversight. It was a lesson learned the hard way, and one that still makes me cringe when I think about it.

Thankfully, with modern tools like Nuve Platform, SAP professionals can work on isolated systems, eliminating the impact of their errors on others.

## The role of branching and isolated testing
SAP developers can work in [separate branches in isolated systems](/blog/modern-branching-strategy-for-sap). This reduces the risk of one person's error affecting everyone else. These isolated systems are good for testing both high-risk and regular tasks. Using [CI pipelines](/blog/quick-fix-with-ci-pipelines) in modern branching strategies allows for automated testing. This helps identify problems early and makes sure another person reviews your work, which can prevent issues from making their way into production.

For tasks that can't be done in a branch, like testing add-ons or implementing SAP notes, isolated systems still offer a significant benefit. You can perform a preliminary test to make sure everything works as expected. If a problem arises, you can easily delete or restore the system to try a different approach.

## Goodbye #ABAPfails, hello #ABAPwins
So go ahead, start using [isolated environments](/solutions/on-demand-sap) to code freely and wave goodbye to those haunting SAP scars!

The impact of developer errors in a shared environment

Explore the pitfalls of SAP development in shared environments and learn how modern tools can prevent costly errors.

SAP #ABAPfails

I must admit, I love SE80. I enjoy the familiarity and native integration SE80 provides. That said, there's a growing number of developers who are using VS Code for ABAP development. VS Code is a free source code editor that allows offline editing and most importantly, you do not need access to an SAP system.

## Features of SE80
When it comes to the good stuff, SE80 is like that trusty old Swiss Army knife you can't imagine going camping without. Its seamless integration with SAP systems means you get direct access to all the ABAP-specific tools and nearly all the objects you'll ever need, with a few exceptions like CDS. You've got everything from code completion to debugging features, right at your fingertips. And let's not forget the comfort of working within an environment that's custom-built for SAP—talk about a dream workspace for any ABAP developer!

But it's not all sunshine and rainbows. SE80's design screams "vintage," and not in the cool, retro way. Its user interface could use a facelift, and its functionality, although robust, feels somewhat stuck in the past compared to modern IDEs. While it offers some level of version control, it's not nearly as flexible or user-friendly as what you'll find in newer development environments that leverage Git. So if you're the kind of person who likes their tools to be as cutting-edge as the code you're writing, SE80 might leave you wanting more.

## Features of VS Code with abaplint
While VS Code was initially not focused on ABAP development, the open-source nature of the platform has allowed for the development of extensions tailored to ABAP. This has opened the door for SAP developers to enjoy a more modern development environment with features like Git integration, numerous extensions, and the ability to customize almost every aspect of the editor.


### Leverage extensions
For ABAP development in VS Code, the [ABAP remote filesystem](https://marketplace.visualstudio.com/items?itemName=murbani.vscode-abap-remote-fs) extension allows you to connect to an SAP system, work on ABAP code, and even debug it. The [abaplint](https://marketplace.visualstudio.com/items?itemName=larshp.vscode-abaplint) extension is another gem—it's a linter for ABAP, providing instant feedback and suggestions to improve your code. Both of these extensions significantly enhance the ABAP development experience, offering functionalities that are not readily available in traditional SAP environments like SE80. The availability of such extensions has created an increasingly compelling case for considering VS Code as a viable option for ABAP development.

### Local development with offline access
It's especially handy for open-source development, where developers often don't have access to ABAP systems. Yep, you read that right—you don't need a connection to an SAP system to work on ABAP code. Thanks to abapGit, ABAP development has been decoupled from an SAP system's database. This lets you edit code locally and then push your changes to a Git repo, where it can go through a CI pipeline.

> ### Stay in the loop! Subscribe now for the latest updates. 📩
> <SubscribeForm />

## Comparing costs and setup
SE80 of course requires SAP GUI and an SAP system. This has become more accessible with the re-release of [ABAP Platform 1909](/blog/getting-started-with-the-abap-platform-trial), but the system requirements are still quite high, making it [difficult for everyone to run it](/pricing/personal). In a traditional business setting, the developer doesn't have the burden of costs so it's typically not an issue. Similarly, the setup of SAP GUI is likely to be the responsibility of corporate IT so it's not an effort on the developer.

However, for personal projects or contributing to open source, SE80 may be unavailable. In this case, even with its limitations, VS Code is a suitable option. In fact, the limitations may even be a good thing as it then allows for using abaplint to ensure the syntax is compatible with all versions of SAP BASIS 702 or higher. It does require additional setup on the developer's part but it's a mature enough tool that this can typically be done in a few minutes.

## Key takeaways
SE80 is still the best option for native integration with an SAP system and ideal for developing business features, particularly those that are deeply embedded in standard SAP. However, in some cases, particularly for open source contributions, personal development, or offline access to edit ABAP, VS Code is a great option. 

Ultimately, the key is giving developers the flexibility to choose whatever tools they prefer to optimize the developer experience.

As for me, perhaps it's that old habits die hard but I'll stick with SE80.

Who wins the ABAP showdown?

Comparing SE80 and VS Code for ABAP development, weighing features, costs, and flexibility.

Visual Studio Code vs SE80


### The potluck parable: A glimpse into traditional SAP development

Think about a traditional potluck. Everyone cooks their favorite dish at home in their own kitchen. They have complete control over the ingredients, the cookware, the stove, and, most importantly, the timing. They then bring their prepared dish to share at a communal table. 

The result? A rich, harmonious feast representing the collective effort of all the individual chefs.

### The kitchen chaos: Shared development woes

Now, imagine a different scenario. Everyone arrives at the potluck with their raw ingredients and has to cook their dish in the same kitchen, at the same time. There's a scramble for counter space, burner time, and oven access. Ingredients mix unintentionally, flavors cross-contaminate, and the resulting dishes are a far cry from their intended glory. 

The chaos and confusion echo the challenges faced by developers working in a shared SAP development environment.

SAP developers are forced to write, test, and perfect their code, all while dodging the constant roadblocks of conflicts and managing object locks. It's an environment that's inefficient, slow, and fraught with potential for errors, which puts an undue burden on the developers and stunts the evolution of their creations.

### An orderly kitchen: The power of personal development environments

This is where the adoption of a modern development approach in SAP comes into play, effectively transforming this disarrayed shared development environment into a well-organized and efficient operation. 

Imagine if each developer had their own personal development environment. Here, they could experiment, create, and perfect their code without having to constantly watch out for collisions or lockouts.

### Stirring the pot: The impact of personal development environments

In these personal development environments, developers are free to focus on their task at hand, unhindered by the typical disruptions and distractions that exist in shared spaces. They can give their best, ensuring each piece of code, each function, and each module is crafted to its highest potential. The efficiency and precision that this setup brings about are significant, allowing for faster development cycles, improved quality of code, and fewer errors, thus saving valuable time and resources.

This is the future of software development in SAP - a harmonious blend of individual creativity and collective efficiency. The adoption of personal development environments is more than just an upgrade, it's a complete paradigm shift towards creating a more productive, less stressful, and ultimately, a more effective software development ecosystem.

### Setting the table with Nuve: Transitioning to the future of SAP development

If you're intrigued by the possibilities of personal development environments and want to delve deeper into how to implement them for your developers, we've got you covered. At Nuve Platform, we specialize in making this transition seamless and effective. We believe in empowering developers with the tools and environment they need to excel, and we're here to guide you every step of the way.

In our pursuit to provide you with comprehensive resources, we have compiled a detailed white paper that explains the benefits, the implementation process, and shares customer stories of successful transitions to personal development environments.

[Download the white paper](https://resources.nuveplatform.com/personal-development-environments)

Unlock this invaluable resource and join us in forging a path towards a more efficient, collaborative, and prosperous future in SAP development. Together, we can redefine what's possible.


A new recipe for SAP development environments

Shared SAP development environments can be chaotic. Learn how personal environments can boost efficiency and code quality.

Ever tried hosting a potluck in one kitchen?


In software development, changes are inevitable. Keeping your code reliable can be challenging. Unit testing is a powerful tool that helps developers ensure their code is robust, adaptable, and less prone to errors. 

In this second installment of our ABAP Unit Testing series, we explore the importance of unit tests in ABAP, discuss their benefits, and offer practical examples using SFLIGHT-related data. Be sure to revisit our earlier post on the [fundamentals of ABAP Unit Testing](/blog/fundamentals-of-abap-unit-testing).

Let's dive in!

# Software Evolves

Unit tests focus on validating small portions of your code, such as methods or functions, to guarantee they perform as intended. Integrating unit tests into your development workflow enables you to identify potential problems early, minimizing the time and effort needed for later fixes.

As software evolves, modifications to the code may inadvertently break existing functionality. However, with well-designed unit tests in place, you can detect issues early on. This is crucial when updating code after extended periods or working with code written by others. Good unit tests also serve as living documentation, making it easier for you and your colleagues to understand and maintain the code.

The number of test cases continues to grow as you add functionality. While human testing is essential, keeping track of all test scenarios is challenging and time-consuming. Unit tests, on the other hand, offer a consistent and reliable approach to verifying that existing functionality remains functional.

# Robotic Helper

Have you ever encountered a situation where you need to add a feature and there's a clean way to refactor the code, but you're hesitant to make changes due to the fear of introducing new bugs into production? As requirements change and your code evolves, unit tests can serve as a safety net, ensuring that modifications don't create new issues or regressions. By running your tests after each change, you can confidently maintain the stability and functionality of your existing code. Think of unit tests as a robotic helper assisting you with your work. 

Along those lines, humans sometimes forget. You can automate the execution of unit tests with continuous integration (CI) tools. This approach can further optimize your workflow and enhance your code's reliability.

# Risky? No worries with isolated systems! 

Some tests might be risky, potentially causing harm to the system if executed in a shared environment. Thankfully, ABAP Unit allows you to [define the risk level](/blog/fundamentals-of-abap-unit-testing) for each system, enabling you to run risky tests in isolated systems and harmless tests in shared systems. This way, you can test with confidence without affecting system stability in a shared environment.

# The top 1% of ABAP developers unit test

Top-tier developers recognize the importance of unit testing and make it an integral part of their development process. However, there's an even greater reason to embrace unit testing for those who may not be among the elite developers. If you often find yourself addressing issues later in the development process, implementing unit tests can be a game-changer. By adopting unit testing, you will notice reduced rework and result in happier functional users and a more satisfied boss. By delivering more reliable software, you'll foster a more productive and positive work environment for everyone involved.

# Real-World Example

Before diving into the example, let's briefly introduce the SFLIGHT data model used in this scenario. SFLIGHT is a standard SAP data model that simulates a simple flight reservation system. It includes several tables containing information about flights, carriers, connections, and bookings. In this example, we will be working primarily with the SFLIGHT table, which contains data on individual flights and their seat capacities.

### Initial Requirement

You work at an international airport on their development team. Your colleague, Mary, is an operations manager responsible for monitoring seat capacity and allocation across flights operated by different airlines.

Mary recognizes the importance of having a comprehensive view of the total, available, and used seat capacity for each airline, identified by their carrier ID. This information would enable her to conduct more informed analyses. She requires a solution that calculates and presents these capacity details, streamlining her data analysis and decision-making process.

Mary presents her request to the IT team:

> "I would like a program that can calculate and display the following information by airline:
>
> - Available capacity - The number of seats still available for booking across all flights.
> - Used capacity - The number of seats that have already been booked across all flights.
> - Total capacity - The total number of seats available across all flights.

With a clear understanding of the requirements, you initiate the development of the `ZAIRLINE_INFO` report to address this business need.


```abap
REPORT zairline_info.

CLASS zcl_airline_capacity DEFINITION.
  PUBLIC SECTION.
    METHODS:
      get_available_capacity
        IMPORTING
          iv_carrid                    TYPE s_carr_id
        RETURNING
          VALUE(rv_available_capacity) TYPE i,
      get_used_capacity
        IMPORTING
          iv_carrid               TYPE s_carr_id
        RETURNING
          VALUE(rv_used_capacity) TYPE i,
      get_total_capacity
        IMPORTING
          iv_carrid                TYPE s_carr_id
        RETURNING
          VALUE(rv_total_capacity) TYPE i.
ENDCLASS.

CLASS zcl_airline_capacity IMPLEMENTATION.
  METHOD get_available_capacity.
    SELECT SUM( seatsmax + seatsmax_b + seatsmax_f - seatsocc - seatsocc_b - seatsocc_f )
       INTO @rv_available_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_used_capacity.
    SELECT SUM( seatsocc + seatsocc_b + seatsocc_f )
      INTO @rv_used_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_total_capacity.
    SELECT SUM( seatsmax + seatsmax_b + seatsmax_f )
      INTO @rv_total_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.
ENDCLASS.

START-OF-SELECTION.

  DATA: o_airline_capacity TYPE REF TO zcl_airline_capacity,
        available_capacity TYPE i,
        used_capacity      TYPE i,
        total_capacity     TYPE i.

  CREATE OBJECT o_airline_capacity.

  total_capacity = o_airline_capacity->get_total_capacity( 'AA' ).
  available_capacity = o_airline_capacity->get_available_capacity( 'AA' ).
  used_capacity = o_airline_capacity->get_used_capacity( 'AA' ).


  WRITE: / 'The available capacity for airline AA is:', available_capacity.
  WRITE: / 'The used capacity for airline AA is:     ', used_capacity.
  WRITE: / 'The total capacity for airline AA is:    ', total_capacity.
```

You execute the program and the results look good. 
![ZAIRLINE_INFO Results](/images/blog/real-world-example-of-abap-unit/zairline_info_results.png)

As a skilled developer, you understand the importance of writing unit tests and ensuring the reliability of your code. Therefore, you also create a test class to validate your solution.

```abap
CLASS ltc_airline_capacity_tests DEFINITION FOR TESTING RISK LEVEL HARMLESS DURATION SHORT.
  PRIVATE SECTION.
    DATA: lo_airline_capacity TYPE REF TO zcl_airline_capacity.

    METHODS:
      setup,
      test_get_available_capacity FOR TESTING,
      test_get_used_capacity FOR TESTING,
      test_get_total_capacity FOR TESTING,
      test_capacity_relationship FOR TESTING.
ENDCLASS.

CLASS ltc_airline_capacity_tests IMPLEMENTATION.
  METHOD setup.
    CREATE OBJECT lo_airline_capacity.
  ENDMETHOD.

  METHOD test_get_available_capacity.
    DATA: lv_available_capacity TYPE i.

    lv_available_capacity = lo_airline_capacity->get_available_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_available_capacity
      msg = 'Available capacity for the airline should not be initial'
    ).
  ENDMETHOD.

  METHOD test_get_used_capacity.
    DATA: lv_used_capacity TYPE i.

    lv_used_capacity = lo_airline_capacity->get_used_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_used_capacity
      msg = 'Used capacity for the airline should not be initial'
    ).
  ENDMETHOD.

  METHOD test_get_total_capacity.
    DATA: lv_total_capacity TYPE i.

    lv_total_capacity = lo_airline_capacity->get_total_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_not_initial(
      act = lv_total_capacity
      msg = 'Total capacity for the airline should not be initial'
    ).
  ENDMETHOD.

  METHOD test_capacity_relationship.
    DATA: lv_total_capacity     TYPE i,
          lv_available_capacity TYPE i,
          lv_used_capacity      TYPE i.

    lv_available_capacity = lo_airline_capacity->get_available_capacity( iv_carrid = 'AA' ).
    lv_used_capacity = lo_airline_capacity->get_used_capacity( iv_carrid = 'AA' ).
    lv_total_capacity = lo_airline_capacity->get_total_capacity( iv_carrid = 'AA' ).

    cl_abap_unit_assert=>assert_equals(
      act = lv_total_capacity
      exp = lv_available_capacity + lv_used_capacity
      msg = 'Total capacity should be equal to the sum of available and used capacity'
    ).
  ENDMETHOD.

ENDCLASS.
```

### Change in Requirement
A few weeks later, Mary has a new request to modify the original requirement. 

> Can you update the program so that the available capacity calculation only considers economy class seats?

However, since you are currently occupied with a major project, another developer, Ali, is assigned to handle this feature request. They believe it's a straightforward change and proceed to update the `get_available_capacity` method accordingly.

```abap
  METHOD get_available_capacity.
    SELECT SUM( seatsmax - seatsocc )
       INTO @rv_available_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.
```

Ali executes the program and the results look good. Except they are wrong!

The available capacity value is lower than before, but the used and total capacity did not change. This is because those two other calculations still include business and first-class seats.

![ZAIRLINE_INFO Bad Results](/images/blog/real-world-example-of-abap-unit/zairline_info_bad_results.png)

However, Ali knows that the CI pipeline will automatically run unit tests so he runs then locally. He notices there's an error - "Total capacity should be equal to the sum of available and used capacity". 
![ZAIRLINE_INFO Failed Test](/images/blog/real-world-example-of-abap-unit/zairline_info_failed_test_results.png)

Upon closer inspection Ali realizes that the code is now inconsistent. Available capacity is based on economy but used and total is for all seat types, economy, business, and first. 

Ali assumes Mary meant to update the code to only look at economy class for all values. But instead of just making an assumption, Ali calls Mary and explains the inconsistency and asks her how to proceed. Mary confirms that she wants only the values for economy fares for all calculations.

Ali then updates the code and runs the test again. He also adds a helpful comment. Specifically, Ali updated the `get_available_capacity`, `get_used_capacity`, and `get_total_capacity` methods to consider only economy class seats, ensuring consistency across all calculations.

```abap
  METHOD get_available_capacity.
    " Only consider economy
    SELECT SUM( seatsmax - seatsocc )
       INTO @rv_available_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_used_capacity.
    " Only consider economy
    SELECT SUM( seatsocc )
      INTO @rv_used_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.

  METHOD get_total_capacity.
    " Only consider economy
    SELECT SUM( seatsmax )
      INTO @rv_total_capacity
      FROM sflight
      WHERE carrid = @iv_carrid.
  ENDMETHOD.
  ```

The results look and are correct. 
![ZAIRLINE_INFO Good Results](/images/blog/real-world-example-of-abap-unit/zairline_info_good_results.png)

Ali confirms they are correct by running the ABAP Unit tests.
![ZAIRLINE_INFO Passing Test](/images/blog/real-world-example-of-abap-unit/zairline_info_passing_test_results.png)

Ali then moves this code to the central landscape and to QA for Mary to test. He knows with a high degree of confidence that this code will be moved to production.

To access the complete codebase, please visit the following GitHub repository: [nuve-platform/sflight-demo](https://github.com/nuve-platform/sflight-demo)

# Key Takeaways

Unit testing is an essential part of modern software development, and ABAP is no exception. By incorporating unit tests into your development process, you can ensure that your code remains robust, adaptable, and less prone to errors. This is a simple example that highlights how easy it is to start introducing bugs to your code. In the real-world, programs are often more complex and by not catching errors early you are slowing down the business and increasing the true cost of development. 

With the help of tools like ABAP Unit and continuous integration, you can build a solid foundation for your SAP applications, making it easier to adapt to ever-changing requirements and maintain high-quality code.

Now that you understand the power of unit testing in ABAP, it's time to start incorporating it into your development process. By doing so, you'll not only improve your skills but also contribute to a more reliable and robust SAP ecosystem. 

Happy testing!


Enhance Your ABAP Development with a Comprehensive Unit Testing Scenario

In this hands-on example, we'll demonstrate how unit testing in ABAP can help you build robust, reliable, and adaptable code.

Real world example of ABAP unit testing


## Issue

As the Nuve team became more comfortable [releasing features in pieces](/blog/release-in-chunks), [managing scope creep](/blog/scope-creep), and [testing effectively as we went](/blog/reducing-bugs-again); our development pace and quality increased significantly. This meant that more developers were adding new productive changes to the codebase for every release.

This led to a subtle shift: almost every release included changes from multiple developers, even though we were still releasing one or two times per week. This meant that each release involved changes that were made by someone other than the person who was releasing the code.

Don’t get us wrong, this is a *great problem to have*, but we still needed a way to provide the person who was leading the release with a sense of comfort that they would release all changes without issue.

## Solution

There were two questions that we needed to address:

1. Who runs the release when multiple people have made changes?
2. How does that person release with confidence?

Our solutions were simple and low tech.

**Question 1: Who Runs the Release**

> The person who made the *highest risk* change within the release runs the release.

Generally this is the person who made the most changes, but not always. For example, if a person changed a whole bunch of marketing copy, they probably changed a lot of code. But those changes are very low risk to the to the release process. Changing text is no big deal.

Whereas if somebody changed a whole bunch of user data as a part of a release, that might involve very little code but could be very high risk. So that part of the release would have to run smoothly and the person who added those changes should run it.

**Question 2: How Do They Release With Confidence?**

> Each developer needs to write release notes for changes that must happen outside of the normal release process.

A “normal” release process will vary team to team, but ours was essentially as follows . . .

>First, release the code that runs on our servers:
>
>- Change the back end code
>- Run routine database updates
>- Restart to ensure changes take effect

>Second, release the code that runs in the browser:
>
>- Change the front end code
>- Restart to ensure changes take effect

So that was our starting point. If the release required anything outside of that process, say running a script or installing something new, that had to be added to the release notes. And it had to be added in a foolproof manner. Something like this:

```bash
# Release Notes

#######################
# Server Side Release
#######################
# After pulling code and making routine database updates, run
python3 .../scripts/post_release_script.py

#######################
# Browser Code Release
#######################
# After pulling code, before be sure to run
make build
```

These aren’t actual release notes, but they should get the point across. There should be literally zero judgment calls during the release process.

The best possible process is foolproof. Like, copy/paste this line and press enter, then copy/paste that line and press enter.

## Results

This process led to peace of mind for the developer who ran the release. They could trust that they had all the steps to run the release documented clearly.

Though we used to have minor issues with releases in our early days as a team (”Oh no! I forgot to XYZ so something is broken. I’ll go fix that!”). We haven’t had an issue across dozens of releases after implementing this process.


How we empowered anybody on our team to release with confidence.

Empowering releases


## Issue

After two consecutive experiences that slowed development due to trying to do too much at once, the Nuve team had learned its lessons about keeping pull requests (PRs) small. We were shipping code very quickly. The team was releasing multiple times per week, and those releases were adding up to meaningful customer facing changes.

Then we started to notice some issues. We released to production and found some unexpected user facing bugs. We caught them within a few minutes and fixed them [with hotfixes](/blog/hotfixes). So there was no major issue. But then we had a similar issue with our next release. We found user facing bugs in production and fixed them quickly, but we could have (and should have) caught them in our [QA environment](/blog/release-quality-issues).

The first release with production issues could have been just an unlucky miss, but two in a row felt more like a process issue so we dug in. What we found was that while all team members were releasing smaller bits, not all team members were fully testing their code - or asking somebody else to do so.

## Solution

We needed a process. We didn’t want it to be too cumbersome, but we wanted it to be effective. We settled upon asking for the following. For each PR, the person who wrote the code must:

- Include a checklist of test cases - user actions that would prove the change worked and didn’t break anything - or
- Include in the PR a reason why a list of test cases wasn’t necessary

This may sound cumbersome, but our previous [two](/blog/release-in-chunks) [learnings](/blog/scope-creep) were about keeping PRs small. So we were creating small PRs. Small PRs, almost by definition, meant that the number of test cases per PR should be small. And the test cases should be exactly the test cases that the developer used to test that their own code was working in their own [isolated dev environment before](/blog/isolated-development-environments) they created the PR.

So essentially we were asking the team members to *think more carefully* about the test cases from the user perspective, and then use those user facing tests to test their own code. Writing the test cases in a PR when this has been done properly is easy.

The other benefits of this process are that tests:

- Can be confirmed by someone other than the person who wrote the code on the QA system, and
- Can be run again to double-check mission critical tests in production if desired

We were essentially writing a test plan in a distributed fashion.

## Results

Bugs fell basically to zero over the next dozen or so releases. It was, and continues to be, very successful at preventing production bugs.

And the burden for checking it is very low. Any reviewer should ask for a test plan whenever they don’t see it, and that should prompt the developer who wrote the PR to write the tests *and to run them*.

The interesting irony of this exercise is that the process of requiring the test plan *almost* makes running the tests unnecessary. The vast majority of the quality improvements come from the developer carefully considering what could go wrong, running the tests themselves, and ensuring they pass. They will almost certainly pass in QA and on production if they passed locally because of the quality of our team’s development environments.

We still do run the tests to confirm, though. And that gives us peace of mind that our end users won’t experience any bugs.

## Aside: Iterating Toward Better With Agile Cycles

This experience highlighted a repeating pattern. First, we would do something to speed up our pace of development. Then we would encounter bugs due to the increased pace. Then we would fix the issues leading to bugs, losing a bit of speed. Then we would push to increase our development pace again, starting this cycle all over again.

This wasn’t a two steps forward, two steps back, pattern. We were continuously improving in spite of small setbacks along the way. Overall the trend has been toward faster development *and* higher quality releases.

It can be frustrating to notice yourself or the team forgetting and relearning lessons that could have been learned before, but this is how it goes sometimes. We’re human. This type of pattern is typical of the agile development process. Improvements are not perfectly linear, but progress is organic and continuous.


How we became more thoughtful and improved quality.

Nuve started requiring test criteria for each pull request which reduced bugs signficantly.

Reducing bugs, again

## Session: DevOps for SAP with Isolated Development Environments

Nestor Lara, Nuve's CEO, and Mary Murphy, Technical Product Manager, show how to develop faster with higher code quality using isolated SAP development environments for each developer or each team.
 

<iframe width="560" height="315" src="https://www.youtube.com/embed/Shha3KQikmM" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen style={{display: "block", margin: "0 auto"}}></iframe>

Detailed agenda with timestamps are available at the bottom of the post.

## Testimonials and Feedback

<div style={{"max-width": "550px"}}>
 

![tweet1.png](/images/blog/tweets/tweet1.png)
([source](https://twitter.com/cyclingfisch/status/1593241914014257153))

![tweet2.png](/images/blog/tweets/tweet2.png)
([source](https://twitter.com/marcfbe/status/1593265852316516353))

</div>

## Detailed Agenda with Timestamps

[Introduction](https://youtu.be/Shha3KQikmM?t=0)

[Presentation Overview](https://youtu.be/Shha3KQikmM?t=86)

### Motivation

[Why Use Isolated Dev Environments?](https://youtu.be/Shha3KQikmM?t=140)

[The High Level Playbook](https://youtu.be/Shha3KQikmM?t=207)

### Isolated Environments
[Background](https://youtu.be/Shha3KQikmM?t=299)

[Benefits](https://youtu.be/Shha3KQikmM?t=334)

[How It Works](https://youtu.be/Shha3KQikmM?t=380)

[Demonstration - Starting a New Isolated Dev System](https://youtu.be/Shha3KQikmM?t=430)

[Benefits of Production Like Data](https://youtu.be/Shha3KQikmM?t=505)

[Benefits of a Clean SAP Landscape](https://youtu.be/Shha3KQikmM?t=570)

### Distributed Development

[Overview and Benefits](https://youtu.be/Shha3KQikmM?t=663)

[Demonstration - Non-Blocking Parallel Work](https://youtu.be/Shha3KQikmM?t=755)

[Continuous Integration: Git, Testing and Version Control When Dev Speeds Up](https://youtu.be/Shha3KQikmM?t=925)

[Demonstration - Continuous Integration (CI) Workflow](https://youtu.be/Shha3KQikmM?t=1149)

### Conclusion

[Conclusion](https://youtu.be/Shha3KQikmM?t=1300)

An overview of how to develop in parallel isolated SAP development systems

A solid overview of parallel development in 25 minutes.

TechEd 2022

This is part of our ongoing series on Agile in Practice, which shares our journey learning to ship higher quality software faster. More related posts are available at the bottom of this one.

## Issue

With our insights related to [chunking big features up across multiple releases](/blog/release-in-chunks) and [solving release quality issues](/blog/release-quality-issues), our development and release cycles sped up a lot. After several cycles with great progress and very few bugs, our confidence grew. This led us to think bigger, which was a great thing. But paradoxically, as our ambitions grew, our pace of development started slow.

As we dug in to what was happening, we realized our increased confidence led to subtle behavioral shifts that decreased our pace of development.

Update meetings were turning into brainstorming sessions, rather than updates, and this was leading to bigger code changes. “While we’re doing this, why don’t we also . . . “ was a common phrase. As we generated more and more ideas, we’d try to sneak them into our current work. We were moving fast, after all, so we could make a few extra changes here and there. It should’ve been obvious that we were [forgetting learnings from our last experience](/blog/release-in-chunks), but overconfidence has a way of blinding people, us included.

It was good that we were humbled so quickly by slowing releases. Looking back at the behavior with more humility, we saw the underlying cause clearly: scope creep. Projects were expanding mostly because we felt so fast. But this expansion increased complexity, slowing our work and undermining the productivity gains we had made.

## Solution

We needed our discipline back. So we started to focus in on our behaviors. There were some common patterns that arose. Here are a few examples and the associated solutions.

### 1. Language That Signifies Scope Expansion

The number one phrase our team is: “While we’re doing this, why don’t we . . . ?”

This would be a dead giveaway if the person explicitly said, “ . . . why don’t we *also* . . .” with emphasis on the “*also”*. Because “also” means that we are explicitly expanding scope, we know what we’re dealing with. People usually omitted the “also”, so we had to pay close attention.

Other examples of the same type scope expanding language:

- “This is great, but could we . . .”
- “Wouldn’t it be cool if . . .”
- “While I was in there, I thought I should . . .”

Notice how all of these phrases could include the word “also” without any loss of meaning. That signifies scope expansion.

Call out the scope expansion and provide a place to document it for later.

Calling out the scope expansion would be enough to keep the pace of development moving, but sometimes really good ideas arise in scope expanding statements. People are excited to see or hear about functionality for the first time and they want to add to it. So we chose to capture ideas as they arose and set them aside. That way they were acknowledged and remembered, rather than simply dismissed as scope creep.

### 2. Unclear Ending Points Invite Scope Expansion

When a developer can’t describe clearly when they will be done with a project and what that ending point looks like, then the project is more likely to expand. It seems obvious when stated so clearly, but it’s tougher to detect in practice.

In the real world, everybody is trying to move quickly. So questions don’t always get asked and answered. When people do ask questions, it’s sometimes uncomfortable to put someone on the spot with a pointed question. It’s especially uncomfortable when you think they might struggle to answer. But there are ways to deal with these issues.

Even if it’s uncomfortable, the team has to ask clear questions, which are:

- When will this be done?
- What will this look like when it’s done?

Then wait for a response. If the lead can describe what done looks like in a way that you can understand, and their timeline is in the right ballpark, then the project will finish close to the given timeline. If they cannot describe the finish line, or their timeline is way off (especially on the short side, paradoxically) that’s an issue. If they waffle a lot, then the project is probably too big and needs to be chunked up.

Note that these questions are very different from the leading questions:

- Will this be done by XYZ date?
- Do you know what needs to be done to finish this project?

These two questions are yes/no answers and the answers will generally be “yes” to both, because that seems like the acceptable pair of answers.

### 3. Leadership Suggestions Are Interpreted as Scope Expansion

Executives - especially those with Director, VP or C in their titles - will often offer suggestions. Sometimes this can be helpful, like if the team is stuck. It gets them unstuck. Other times, it can be unhelpful, like if the team is just about to finish something. We’re going to talk about the second situation here.

The leadership coach Marshall Goldsmith has a great saying about this. He says for leaders, “suggestions become orders.” And that happens whether you want it to or not.

So imagine that a team member is basically done with a first version of a project, and they’re talking about it in an update meeting. Then somebody with a C in their title says, “Wow that’s great, and it’ll be especially awesome when this one extra thing is added.”

The team member’s focus shifts immediately from “Wow that’s great!” - which is what the exec probably intended to say - to “especially awesome when this one extra thing is added.” The executive just subtly redefined done to mean when that extra thing is added. It’s a scope expansion, whether it was intended to be or not.

The reason this one is hard to solve is that it requires one of two things:

1. Executives need to exercise restraint, or
2. Team members need to (somewhat) disregard what executives say

We’ll come out and say Option 1 is easiest if it’s possible, but sometimes there is an executive that can’t reign it in. In that case Option 2 is the only option.

Organizations deal with Option 2 in many ways. The most common is to put a buffer - usually a product manager or engineering leader in between the executive and the people who are doing the work. Sometimes teams manage through language - the executive has to explicitly say that something is required before launch. Sometimes the language is even tied together with a cooldown period - the executive needs to wait 24 hours and come to the same conclusion that something is required for the team to move on it. As long as the executive buys into the process, it can work.

### 4. Some Team Members Bias Toward Scope Expansion

This is a more subtle version of scope expansion than executive suggestions, but it’s in the same vein. Some team members have a natural desire to make projects bigger. They want to see the whole vision executed, which is excellent. Their natural bias is to try to do more, which is helpful much of the time.

Sometimes, though, these team members take a simple project and make it complicated. Possible reasons for this are many. Maybe they want to do something big, so when asked to do something small, they try to do something big anyway. Maybe they are super confident and think they can finish more than they can in a given time horizon (and maybe they’ve even done that in the past). This type of complication isn’t an issue until it is.

When it becomes an issue, it’s generally because the team needed something done to keep moving ahead as a team. The individual, with all the best intentions, quietly expands the scope of their portion of the project, but fails to:

1. Finish the thing the team was relying upon first, or
2. Communicate the expansion to the team

As a result, the whole team is surprised one day to learn that their collective work is on hold until the thing the team was waiting on is done.

There are two ways of looking at this issue. The first way is to call it a team member issue, and to ask them to change their ways. The second way of looking at it is to call it a management issue.

We tend to believe that the more it happens, the more it’s a management issue. The first time a team member does something like this, we can say the team member should’ve communicated better. The second time that team member does something similar, it’s still mostly on them, but the manager should have been paying attention. The *third* time, the responsibility for the miss is definitely on the manager.

It’s a manager’s responsibility to notice patterns of behavior and to make the most of them. If the highly motivated team member is constantly trying to *do more*, then the manager has to figure out a way to channel that productivity. The team member should be able to at least do less (what the team needs) in less time first, and then do more. Or they should be asked for specific updates daily, especially when a project is taking too long, so nothing comes as a surprise.

In other words, once there is a clear behavioral pattern within the team, the manager has to find a way to manage the pattern.

## Results

The four patterns above all showed up in our processes from time to time. Some were more significant than others. As we learned (and continue to learn) to catch them and address them, we re-instilled discipline into our practices.

We now recognize who on our team has which biases, who can help to support each other with scope definition, etc. and how to call each other out when scope expansion occurs. We don’t do it perfectly, but we do it pretty well. And we’ve moved back to one-to-two times per week release schedule that always contains something meaningful to end users.


How we learned to recognize scope creep and manage it.

Dealing with scope creep


## Issue

Nuve knew customers wanted to host their systems on the cloud hosting provider of their choice within their own cloud environment. We had set clear objectives and leadership to carry the project through to completion.

We take a hands-off approach to managing implementation, embracing and enabling ownership and autonomy. The lead on this project decided to release this functionality all at once, suggesting that a big push would be faster and cleaner. We targeted six weeks, give or take a couple of weeks, to complete the project.

About a month went by and nothing had been released. Verbal updates were coming, but there wasn’t any code yet.

So we started to inquire about timelines. The response: next week code would be ready for review. Then next week came and went with no review. The timeline was updated to the following week. That deadline came and went. And that cycle continued a couple more times.

So we hit pause and pulled the project lead aside. We learned that the person was feeling stuck. They had made progress, but finishing was proving challenging. So we asked them to share the changes thus far so we could get more insight into what was necessary to finish the project.

After seeing the outstanding changes, a few tactical things became clear.

**The changes touched all parts of the codebase, which was leading to code conflicts**

Almost every time another team member released some code, the lead on this project would have to re-do some of their code to incorporate the conflicts from the newly added code. This was very cumbersome and tiring.

**Partial progress had been made on multiple integrations, but no single integration was complete**

Part of the reason that nothing had released was that nothing was complete. Releasing the changes as is would’ve broken existing functionality and would not have added anything new. If we wanted to release everything at once, it would be a while before *everything* would be done.

**A lot of effort had been devoted to refactoring code, which increased the risk of bugs in existing functionality**

On top of adding new functionality, we were re-writing old code in new ways to try and simplify the overall code environment. This was a good idea in theory, but it added a new layer of risks to an already large set of changes - we might accidentally break old functionality when releasing new functionality.

**In Summary: This Change Had Become Way Too Big**

The issue here was the execution strategy. We were trying to change too much all at once, and the complexity of releasing everything at once had become unmanageable. Too many things could go wrong.

We needed a different path.

## Solution

We transitioned leadership of this project to a team member had experience dealing with situations like this. They outlined the following plan.

**Step 1: Merge in the Outstanding Changes and Ensure Existing Functionality Works**

The point of this step was to move the unmerged changes into the codebase. That would enable the team to integrate new features into the project code in a distributed fashion, rather than forcing the team managing this change to integrate everybody else’s work.

That, then, would free up the the project team to make progress on completing the work rather than fixing conflicts.

This had to be done quickly, within one release cycle. Because if it took longer, it would block others’ work.

**Step 2: Release Functionality Feature-by-Feature Across Multiple Releases**

After stabilization, we prioritized releasing user facing functionality frequently so we wouldn’t get stuck with large chunks of unmerged code again. This would enable us to demonstrate progress more clearly as well, and with estimated dates for each chunk of features to be released, we would know if we were ahead of or behind schedule.

We would test these new features as we went to ensure the ongoing stability of the user experience.

The principles we followed here were our critical learnings and are outlined in full below.

## Results

The team completed Step 1 - merging in big changes and ensuring existing functionality works - within one week of transferring ownership of the project. That paved the way to work more quickly, releasing in chunks, as expected.

The remaining features were released in weekly or twice-per-week releases over the course of the next few weeks. Because we were exposing well-prioritized features as we went, we were able to set up our first customer on a new cloud provider one week ahead of our scheduled launch date. The functionality had not yet reached our full vision for the project, but it was sufficient to meet their needs.

The full planned implementation was completed one week behind schedule, but no customer work was directly affected by missing that internally imposed deadline. We had achieved the *customer* milestones ahead of schedule because we released bit-by-bit.

## Actionable Take Aways: Principles for Releasing Features Chunk By Chunk

Releasing functionality chunk by chunk was the most critical learning from this experience. In fact, if we had followed this practice from the beginning, we wouldn’t have become stuck in the first place.

Now all of our development follows these principles.

**Principle 1: Small PRs (Smallest Possible User-Complete Feature)**

If you’re making a bug fix, just fix the bug. The change could be just one line. That’s fine because it’s easy to review, easy to test, and easy to call *done*.

If you’re releasing a feature, just finish the feature. Package it up, get it reviewed, and ship it out. Then do the next change.

It’s tempting to expand things, but remember you can always expand things *after* the first working version is shipped.

**Principle 2: Separate Features and Refactors / Cleanups**

One of the most common ways that small things become big is when developers decide, “oh, while I’m in here, I’ll also make this other change.” Not saying you should *never* do that, but 95% of the time it’s best to finish what you’re doing first. Then ship it, then go back and make the other change.

When in doubt, try a 5 minute rule. If you can do the cleanup or refactor in 5 minutes, go ahead and add it to the current feature work. Set a timer (not kidding). The change can’t be that big if it can be done in five minutes. But if it’s been 5 minutes and the change is not done, be really, really honest with yourself. The first estimate was wrong. Maybe there was something unexpected that also needed to happen that added complexity, or there was another “little fix” that popped up.

There’s always a reason to try to do more or to add something else, but seriously, just finish the original feature. After that feature is done and in review, start the bigger refactor or cleanup in a new PR.

And if you realize the current feature *requires* a big refactor to be finished, that’s something to flag to the team ASAP. You’ll probably want to refactor first (in its own PR) and then implement the feature (in a separate PR).

**Principle 3: If You Must Launch All At Once, Still Release in Pieces, But Hide The Pieces Until Release**

Let’s say the business wants to release a big feature set or even a whole product all at once, big bang style. That might sound like a justification for making a whole bunch of changes and merging them all at the same time.

Don’t do it.

It’s generally better to hide the upcoming changes, release them in little bits, and test as you go. It usually doesn’t take long to hide the features. Hack in a little change so that only the internal team can see it (this is known as a “feature flag”).

Then when you’re a week from the release date and leadership asks, “How’s this going?” you can calmly show them where what’s done explain it’s already working in production today. You’ve just hidden it and are completing final testing.

Then tell a story about a botched release you experienced when everything was merged on release day and explain how you wanted to avoid that experience. Ask for a promotion when the release happens seamlessly.

**Summary Principle: Merge Changes as Quickly as Possible**

If you’ve done the above, this should become easier. The point here is that you want to avoid code change conflicts between developers, if possible. If you use git, it’ll flag conflicts them, but not having them at all is smoother.

Our team moves pretty fast. Fast enough that if our code has been sitting on a branch for more than a week, odds are it’s starting to get stale and will run into someone else’s work. This “week long” rule of thumb changes under the following circumstances.

*Bigger Changes Need to be Merged Faster*

The more files or objects your changes touch, the more likely you will run into a conflict. Make those changes fast, test them (well but) fast, and merge them fast.

*Faster Moving Teams Need to Merge Faster*

This sounds like it’ll happen naturally, but think about it like driving on the highway. You need to move with the pace of traffic. If everybody else is going 60 MPH (100Km/h) and you are going 30MPH (50Km/h), you’re gonna slow everyone down because they have to weave around you.

*Given a Fixed Codebase Size, Bigger Teams Need to Merge Faster*

Think about fitting 5 people into a small room. You have some space between everyone and are unlikely to step on each others toes. Now put 30 people in that room and the odds of people stepping on others' toes goes way up.

Same with code. Merging your code is like stepping out of the room to free up space. So do that a lot, but also note there is a limit to how many people you can have working on a certain size codebase.


How splitting up big features over releases saves time and headaches.

A big project stalled and we re-started it by splitting it up into smaller pieces.

Release big stuff in chunks


## Background

Sometimes there are leaps in technology that seem so sudden that they require completely resetting the belief system about what is possible.

SAP teams are being confronted with some of these changes today thanks to advancements in other parts of the tech ecosystem over the last 20 years. New capabilities seem unbelievable, even when seen first hand. But we encourage you to have a look - talk with us if you want to see anything in action - and think about how they could change your business.

## Illustrating the Impossible: SAP Client Demo Mini-Cases

It's easiest to understand these advancements by example. So we will present the advance through a series of mini case studies all focused on the process of demoing an SAP S/4HANA system (fully functioning, with data) to a customer in a pre-sales setting.

## Replica S/4HANA Systems Can Be Started in Under 10 Minutes

Imagine sitting with your team the morning before a client demo and saying to a team member, "Hey, can you start up that demo system we're going to be using this afternoon so we can do a last trial run?" Then they do it and a rehearsal demo system is ready in 5-10 minutes.

We generally hear two reactions to this anecdote.

1. It sounds impossible unless a. the system is on an existing machine that was shut down last night and b. the team member you spoke to was a basis person.
2. It sounds utterly terrifying. What if the machine doesn't start correctly? What if it takes too long to debug the startup process and we're not ready for the demo? What if we mess up the system that we spent so long configuring for today's demo?

If either of these was your reaction, it's time to update your beliefs.

It's now possible to start up a pre-configured replica of an SAP demo system in less than 10 minutes. It works every time. You can do your full demo, then shut down the system, and restart a fresh one with data refreshed as if you never ran the demo in the first place. The refresh also takes less than 10 minutes.

Even when we tell our customers that they can do this they sometimes shake their heads talking about how it's too risky. Then we show them how to do it. Then we show them again. Then they try it themselves. And finally they start to believe.

The backup is there. It starts up the same way every time. And it works every time.

## Backups Are Easy and Reliable

Now imagine your functional team spent the last day customing a demo S/4HANA system to show industry specific data to a prospect. The end of the day comes and someone says, "Good day's work. Go ahead and back up the system so we can shut it down to save some money on our compute costs." In 15 minutes a backup is ready with your day's progress and you shut shut down the system from your smartphone.

Again, we generally hear disbelief - that's impossible! - and expressions of fear.

It is quite possible. With Nuve Platform, backing up a system takes between a minute and a couple dozen minutes depending upon the size of the system. Custom client demo systems usually take 5-10 minutes.

We are generally surprised when we hear the reaction that backups are high risk. Our experience has shown the opposite! Backing up a system at the end of each day means that the team will lose *at most* one day of work, no matter what happens.

If a data center experiences a natural disaster, you have yesterday's backup. If a developer makes a major mistake and corrupts critical data, you have yesterday's backup. If anything fails, you have yesterday's backup. And you can restore your system from that in less than 10 minutes.

For these reasons, we do regular backups on our own systems as a standard operating procedure.

## Demo Systems Can Be Shut Down Daily to Save Costs

We won't rehash the initial disbelief and concerns we hear about this practice. They've already been addressed above.

Rather, we'll note that shutting down systems while preserving progress is easy, and it can save a lot of money. Have the team follow this process:
* Take a backup at the end of the day
* Shut the system down
* Start a new system from the backup the next morning

The total time to do this is negligable. The backup/shutdown can be done on a smartphone while leaving the office, and the startup process can be done while getting a cup of coffee in the morning.

And shutting down demo systems at the end of the day saves *a lot* of money. The vast majority of the cost of running an S/4HANA system is the large hardware cost. In a cloud environment, this cost is charged per hour. If you can cut those costs by 66% by only running the system 8 hours per day, that can add up to thousands of dollars in savings per month.

## Conclusion

We outlined three practices today that sometimes seem impossible to people working with SAP S/4HANA:
* Starting a fresh demo system in 5-10 minutes, either blank or from a backup, to do customization work
* Backing up progress daily at the end of the day to reduce demo customization risks
* Shutting down demo systems at the end of the work day - after backing them up - to cut costs while saving progress

These practices are now possible, and not hard to do with infrastructure automation with Nuve Platform. And the use cases go beyond demo systems.

If you're still doubtful - or if you believe us completely - and want to see this in action, feel free to schedule a demo or take a trial.



New SAP demo creation techniques that seem magical.

It's time to reset your belief systems around modifying and demoing SAP.

That's impossible! New S/4HANA demo techniques that will challenge your beliefs

This is part of our ongoing series about Agile in practice. You can get up to speed on where this post by starting [where we began](/blog/agile-where-we-started). 

## Issue

Nuve was fresh off a win [fixing the vast majority of our release quality issues](/blog/release-quality-issues). Our QA environment was a great end-to-end testing ground.

But one day we had a bug slip through that end-to-end QA process. On top of that, a developer on the team had already merged a new feature int our QA environment that wasn’t fully tested. That meant we couldn’t make the fix on QA and release immediately to production - there was too much risk that the new code on QA could lead to new bugs.

We needed a way to release a fix to production bypassing our normal QA process.

## Solution

### Agile Brainstorming: Options for Solving

**Possibility 1: Make a fix on QA, Test, and Pluck that Commit into Production**

This is a promising idea. Theoretically you can make a fix and move that fix into QA and then pluck just that change from QA into production, ignoring all other changes on QA.

In practice, though, it’s kind of messy to do that. Not a lot of developers - even very good ones - know how to pluck just one or two commits from one branch into another. It’s a non-standard workflow with lots of room for error. Also, the more attempts there are at a fix (i.e. the more commits there are) the more complicated this pattern becomes.

We wanted something a little bit more foolproof when working with production so we passed on this idea.

**Possibility 2: Hotfix Workflow - Fix on Production, then Move those Changes into QA**

This idea is exactly what it sounds like. We create a feature branch off of `main` (production - like we used to when we used the GitFlow workflow). Then make the changes we needed to make to fix the bug. Then we merge the feature branch right back into our `main` branch AND into the `develop` (QA) branch when we prove the fix works.

We only do that for speed when we know that there is a bug on production and we can’t do a full release from QA to production. It’s like a safety release valve for making fast fixes.

This was the process we chose to do.

### Implementation: The Workflow

Because we had separated our QA (`develop`) and production (`main`) branches, we could do the following:

- Create a branch `hotfix-xyz` off of `main`
- Make the fixes we need to make
- Merge `hotfix-xyz` back into `main`
- Deploy to production and test that it works (repeat if not)
- Merge `hotfix-xyz` into `develop` once it works as expected

At the end of that process, both `develop` and `main` (QA and Production) have the fix and we didn’t risk merging anything from QA to production that wasn’t fully tested. We are confident about this because `develop` never merged into `main` !

Further, we always were doing the same simple deploy process

- On production - pull code from `main`
- On QA - pull code from `develop`

Just like any other release. No magical git commands required.

## Results

Because there was little overhead associated with fixing production and the flow was simple, everybody on the team could do a hotfix and we knew we could do it quickly. We saw this in results. Our average time from production bug discovery to fix dropped from several hours to 30 minutes after this change was implemented.

But arguably the biggest win with this process was that it inspired confidence. We knew that our QA environment (`develop` branch) was open for new features as soon as we completed a full release to production because we could always hotfix production if necessary.

We rarely hotfix because our QA process is strong - there have been 3 or 4 hotfixes in the last several months - but knowing that we can hotfix enables us to work quickly in QA.


Inspiring confidence by allowing quick production fixes.

Adding a hotfix workflow to our toolkit inspried confidence in both our development workflow as well as our release procedures.

Peace of mind with hotfixes


This is another addition to our ongoing Agile in Practice series. You can get up to speed on where we were by looking at [where we began](/blog/agile-where-we-started).

## Issue

**Background: The State of the Product**

Nuve had developed an increasingly complicated product that linked code across 3 different codebases: Front End Interfaces, Back End Orchestration, and SAP Systems running on cloud infrastructure.

We had done a good job writing automated tests to check functionality within each codebase, which led to low bugs within front end code, back end code, and SAP systems.

**Background: Our Git Workflow**

We were using GitHub Flow, which essentially was:

- Our `main` branch was regularly deployed to production
- Our `feature` branches were always branched off of `main` then merged back into main
- Automated tests were run prior to releasing `main` to production after `feature` branches were merged in

**The Issue that Arose**

While our automated tests would pass, signifying that our Back End, Front End, and SAP Systems were essentially bug free, we would sometimes see user facing bugs after release. That’s because, while the code within codebases were well tested and therefore bug free, the interactions *between* codebases were not always well tested.

For example: A user might do something that wasn’t allowed - something that should show a helpful error message. Our back-end codebase *was sending* an error message to the (separate) front end interface codebase. But the front end codebase didn’t know how to handle the message. So it wouldn’t show anything to the user, and the user would get stuck. They didn’t get any feedback that they had done something incorrectly, which led to frustration.

There isn’t really a way to write a unit test for this type of bug because the issue sits at the intersection between two codebases. It’s an “integration test” issue because it arises at the integration point between two systems.

## Solution

### Agile Brainstorming: Options for Solving

We considered a number of possible solutions

**Possibility 1: Write Automated Integration Tests**

Good idea, but in practice, we had seen automated integration tests become very time-consuming to build and maintain, so we filed that away as something we might do in the future.

**Possibility 2: Test all Integrations in Your Isolated Development Environment**

We decided to do this, because it’s a good practice to test your own code end to end. But it wasn’t quite enough to give us peace of mind because a) it put all responsibility on to one developer to think of every test case, and 2) it didn’t allow us to test complicated releases that could cause issues.

**Possibility 3: Create a Production-Like Quality Assurance (QA) Environment**

Basically, we would clone our production development environment (with the exception of sensitive production customer data), and we would release changes here prior to releasing them to production.

This was the idea that really met our needs. It enabled us to do the following:

- Test our release to a production-like environment to ensure our production release would go smoothly
- After release, all developers could test each others’ work prior to the production release - more eyes meant more opportunities to catch bugs
- And it had additional benefits:
    - If you had never released to production before, this was a good place to practice
    - If you had to make changes to infrastructure (eg. web or database servers), you could test those changes before making them in production, reducing the chances of an infrastructure issue

### Implementation: A New Git Workflow

This led to an interesting question: Should we just release our `main` git branch to QA and then later release it to production after testing on QA? Or should we do something else?

There were good arguments in both directions, but given how easy it is to merge one branch into another using Github, we settled on creating a new branch which lead to the following equivalency:

- `main` branch = Production
- `develop` branch = QA

In other words, everything that is on `main` should be well tested enough to release to production (and production releases should happen quickly after changes are merged into `main`).

Also, everything that is on `develop` should be well tested enough to release to QA (and QA releases should happen quickly after changes are merged into `develop`).

In summary, our git workflow became:

- `develop` is branched off of `main` and a production release is merging `develop` back into `main` and deploying to production
- `feature` branches should be branched off of `develop` and merged back into `develop` for release to QA

Simply put, code started to flow like this:


> `feature-branch` (Dev environment) → `develop` (QA) → `main` (Production)

### Implementation: When Do We Merge Features to QA?

We suggested the following readiness principle:


> If you merge a feature into `develop` (i.e. release to QA) you should be very confident that it’s tested enough that you will be able to merge into `main` and release to production within 24 hours.

Essentially, it’s bad form to break QA for a long time because you didn’t test well enough in your own isolated system. That behavior blocks other people, and while they have their own isolated systems, they can only develop in isolation for so long. They are pushing to integrate their code into QA in prep for a production release.

## Results

This change, arguably more than anything else, reduced the number of user-facing bugs in production releases. The bugs became obvious when we tested them in a near-identical-to-production environment.

The change also enforced a degree of discipline leading up to releases. We knew that QA had to be “stable” prior to starting a production release, so people could rally to make that happen if there were bugs on QA prior to a planned release. We also could delay a release (generally for less than 24 hours based on our readiness principle) if we knew QA wasn’t stable.

As a final comment, it might sound like this adds some overhead/maintenance costs to the development process. That is true, but we’d argue that it’s a “good” kind of maintenance cost. Because QA is so similar to production, arguably, every issue that arises on QA *could have arisen in production instead if we didn’t see it in QA first!* In our opinion, it’s better to have those issues arise in QA than in production and to get valuable practice fixing them.


How we significantly reduced our production bugs with strong QA testing.

A QA environment and git workflow improved our production releases, establishing confidence and minimizing risks and bugs.

Solving release quality issues


As a smaller company that had to work quickly with a shoestring budget, we knew we’d have to re-think the SAP development process.

Most of us previously worked on systems that had 2 to 4 releases to production per year, which is understandable in a waterfall process. But this situation was different. We had a very limited budget and lots of experiments to test. Betting our whole company on a handful of releases was out of the question.

We needed to be agile and respond to customer feedback quickly. So we re-worked the entire development process to enable us to release multiple times per week, shipping new functionality and adapting to customer needs as we went.

This series will share twists and turns that our dev process took while we were shipping new functionality. It will illustrate key issues that arose for us and that will arise for most businesses that transition from a waterfall-ish to an agile approach. Mostly, there will be a lot of good learnings shared.

With that in mind, let’s talk about where we began, and what we had.

## What We Had When We Started Our Journey

We started with three key elements in our founding dev process:

1. Isolated Development Environments
2. Github for Version Control
3. Light Automated Checks for Our Code

We’ll share a full post describing each of the above, but here is a brief rationale for each of these key elements.

### **1. Why Isolated Development Environments?**

The short answer: We had to work fast.

Time and cash were our scarcest resources. So waiting in line to use a shared development environment was a non-starter. Further, we had 4 developers on payroll, and the cost of a developer sitting idle was enormous compared to the cost of standing up a new development environment.

We also knew that not everything that we tried would excite our end users. So we needed to quickly implement new features and throw them away if they didn’t work. This would’ve been nearly impossible in a shared development environment.

Therefore, parallel development was our only viable option. And Isolated Environments were the only viable way to develop in parallel.

Note: The full post is now [available here](/blog/isolated-development-environments).

### **2. Why Github Version Control?**

With 4 developers working in parallel, our code changed quickly. Further, we frequently had two developers working in the same part of the codebase who risked changing the same objects.

We needed a version control system that would allow for a large quantity of small changes while alerting us when two people tried to change the same part of the code. Taking a page from the web developer playbook, we used the gold standard: Github.

For ABAP work, we used abapGit.

This enabled - and continues to enable - our team to work in parallel while preventing collisions between our work and often contributing multiple features per day to the codebase.

Note: The full post is now [available here](/blog/git-version-control).

### **3. Why Automated Code Checks?**

Arguably we could have started without automated code checks, but we’re happy today that we had them in place early on.

Essentially, these automated checks kept our code clean. They automatically enforced formatting and style rules. They ensured that our code would at least compile and run without errors. In some cases they checked that variable types made sense.

The result is a codebase that is less likely to have syntax errors and is more readable and maintainable as we continue to build.

Note: The full post is now [available here](/blog/automated-code-checks).

## A Solid Foundation, But Lots to Improve

This foundation set us up for success, but it was by no means the end of our agile journey. The whole point of Agile is to keep improving everything over time - the product, the development processes, the speed of iteration, and so on. And we continue to do that.

The remainder of this series will share the Nuve team’s actual learnings and adaptations over time. There will be some great insights and cases here, and we hope that you enjoy learning from our experiences.


The bare essentials of an agile development process.

Nuve started with a bare-bones agile development setup. This post walks through the basic elements and why each was included.

Agile: Where we started

I frequently come across SAP developers that are eager to innovate but face technology hurdles that limit them. This is particularly frustrating since technology should serve as an engine for growth. This is not just my opinion; it has been proven by all the world's largest companies. If you are not innovating, you risk being passed up by companies that are. So the question arises, how can organizations accelerate developer productivity in an environment where waiting months for a shared development system is the norm?

To answer this, first, we have to thoroughly understand the motivation.

## Can technology drive business value?
Top-performing companies know that internal IT is as critical as customer-facing technology. However, metrics for internal IT are not as straightforward, leading most companies to only see it as a cost center. Too often, the inability to correctly measure ROI leads to missed opportunities.

IT becomes a value driver and innovation engine when the ROI is measured correctly and a framework to improve productivity is in place. Organizations that do not leverage IT as a value driver risk being surpassed by those that do. This blog explores how improving developer productivity is the catalyst for building and scaling high-performing technology and organizations.

## Measuring the unmeasurable
How do you measure developer productivity? It is not as easy as it may seem. If developers are evaluated against the wrong metrics, they will learn to game the system.

For example, if you measure lines of code, it's easy to write overly complex code for simple things. This is not the right approach, as it will quickly lead to technical debt.

So then you might think, let's measure productivity based on the number of transports. That can lead to increased risk as developers may rush to create a high number of transports, increasing the likelihood of a failure in production. Not to mention, transport management also poses risks.

What if you instead focus on the number of features completed. This is not fair since not all features are equal; some are more important than others and vary in implementation difficulty.

An observant reader may note that the metrics above are sacrificing speed or stability. And, of course, we want it all!

## No trade-offs between speed and stability
Instead of measuring productivity via isolated metrics, consider adopting the framework based on Accelerate.
1. Delivery lead time - the time it takes for a feature to make it from the first line of code to production
2. Deployment frequency - the number of deploys to production
3. Time to restore service - the time it takes to correct an issue in production
4. Change rate fail - the percentage of deploys that cause production issues

When these metrics are optimized collectively, you notice that there isn't a sacrifice between speed and stability. Instead, you set the foundation for becoming a high-performing organization. Elite IT teams achieve the following results:
1. Delivery lead time - less than 1 day
2. Deployment frequency - on-demand
3. Time to restore service - less than 1 hour
4. Change rate fail - 0-15%

## Culture guides everything
Metrics, frameworks, and technology are valueless if you don't also establish a healthy organizational culture.

 Healthy Culture 
The right metrics are used for positive change

 Toxic Culture 
Metrics are used as tools for control and culpability

Culture and process go hand in hand; they can be mutually reinforcing or mutually destructive.

Consider the shared DEV and QAS systems we've grown used to in the SAP world. These shared systems are intrinsically risky. As developers, we have the potential to break them, which would negatively impact everyone else on the team. So to mitigate the risk, companies put in processes and procedures that adversely affect productivity. With containerized SAP systems, you can eliminate the risk of adversely affecting others, allowing for a culture where you are free to try anything in your container.

## The modern approach to SAP development
You've likely heard it, "implement DevOps!"

DevOps is a broad term that is often overused or misused. Instead, you should focus on implementing CI/CD pipelines. Leveraging several established best practices that include:

* Isolated development ([personal SAP systems](/blog/accelerate-developer-productivity) on Nuve)
* Intuitive version control (GitHub, GitLab, etc.)
* Test automation ([ABAP Unit](/blog/fundamentals-of-abap-unit-testing), [abaplint](https://abaplint.org/))
* Test data management ([refresh SAP systems in minutes](/blog/abap-unit-testing-approaches) with Nuve)
* Git-based workflows ([abapGit](https://abapgit.org/), GitHub, etc.)

Implementing these best practices puts you in a promising position to increase productivity. Coupled with a healthy culture, your IT team can provide a competitive advantage and pass up competitors that do not value the performance of software delivery teams.

**Credits:** Accelerate: The Science of Lean Software and DevOps by Nicole Forsgren Ph.D., Jez Humble, Gene Kim

**Credits:** Photo by [Carl Heyerdahl](https://unsplash.com/photos/KE0nC8-58MQ) on [Unsplash](https://unsplash.com/)

Leverage containerized SAP systems for DevOps

Learn how to improve developer productivity, the catalyst for building and scaling high-performing technology and organizations.

Accelerate developer productivity

1. Your [technical debt](#technical_debt) is out of control, and it takes you weeks to move transports to production.
2. You use [sandbox systems](#sandbox_systems), but they take a lot of time and money to provision, only to have the data quickly become stale.
3. Your [project-based development](#project_based_development) has numerous challenges, and you never ship on time.
4. Your [transition to S/4HANA](#transition_to_hana) will take years and require significant effort from your already overburdened team.
5. You need to [validate processes](#validate_processes) but are restricted by the system landscape.
6. Testing [cross-system compatibility](#cross_system_compatibility) is unattainable.

Chances are you have at least one of these pain points in the SAP space. Luckily, we can mitigate or eliminate these issues with modern technology.

Please post in the comments if you would like a deeper dive into any of these issues.

<h2 id="technical_debt">Technical Debt</h2>
 Problem 
Technical debt is primarily due to the centralized architecture of SAP. Centralized development is when all development and configuration occur in a shared system. This shared space introduces numerous challenges.

* The quality of the data quickly degrades.
* To test your results, you need to move your code or configuration back and forth from DEV to QAS.
* It's challenging to update existing code since you don't understand the implications. Instead, you add to it, making it more complex and keeping obsolete code buried in your system.
* Changes are in disparate areas (data dictionary, report, class, methods), making it difficult to conduct peer reviews.
* Static analysis is tedious to set up, and manual checks are slow and error-prone. Think of anything hindering your workflow, and you accept it as "this is the SAP way."

 Solution 
Modern development relies heavily on testing, which requires ephemeral systems. Ephemeral systems are used for a specific purpose and can live for as short as a few minutes. Consider an SAP system that spins up in three minutes, runs unit or integration tests, reports the results, then is deleted. This system likely ran thousands of tests and modified the database, so it should be short-lived. Implementing this type of modern architecture requires the use of containers.
 
With containerized SAP, you can implement a modern workflow. Your workflow should facilitate peer reviews, run static analysis, validate that unit tests exist and are passing, and merge the code to the main branch of your code repository. Applying this workflow to a feature or bug fix is a pipeline. CI/CD pipelines are popular because they help create higher quality code and deploy faster. CI/CD has been around for over a decade, but it requires ephemeral systems to implement, so it was not previously possible for SAP. Well, it is now.

<h2 id="sandbox_systems">Sandbox Systems</h2>
 Problem 
Sandbox systems are a stepping stone to maintaining a clean system landscape. Typically, sandbox systems are refreshed once per year to facilitate access to high-quality data in an isolated environment. However, this is still not frequent enough, and it's a time-consuming and expensive process. Since users know that they can try anything in a sandbox, the system requires more frequent refreshing. It also involves a considerable manual effort to port the changes from sandbox to development.
 
 Solution 
You need a consistent way to "refresh" the system and keep the data up-to-date. However, you should also have a way to allow users to keep their changes. The last thing you want is a system refresh that wipes a week's worth of development. Do not worry; modern development has a solution for this too! You should be using containers for your sandbox systems. With containers, you can perform a "refresh" in minutes to restore the sandbox to its original state and revert any data changes. Development and config can be saved using abapGit and restored after the "refresh." You can also maintain recent data in your container system by leveraging tools such as SAP TDMS or other available third-party tools. These tools allow you to time slice data from production to keep your containers up-to-date. Using these tools, you can even anonymize/scramble sensitive data to ensure security compliance.

<h2 id="project_based_development">Project-based Development</h2>
 Problem 
If you've been on an SAP project, you've experienced at least some of these issues every single time.

* You run into object locks with other developers or team members.
* You have trouble getting consistent data to test your features.
* You keep a spreadsheet with a list of transports for production.
* You have to handle failed transports when moving to production.
* You experienced project delays.
* You have to implement a code freeze during User Acceptance Testing (UAT).
* You have trouble fixing production bugs found in locked code for the current project.

 Solution 
If you've read these headaches in order, you'll notice I'm starting to sound like a broken record. All these issues stem from the fact that we're trying to run billion-dollar companies using a shared system! Using SAP containers that run in the cloud, you should be able to provide systems for each project team where they can do all of their development and testing. Once the project is ready for UAT, you can move it to your central landscape, but at this point, containers allowed you to perform such exhaustive testing that UAT is nearly error-free. You can even provision production replica containers for your UAT team to work as efficiently as possible. Since the container systems run in the cloud, you provision them on-demand and delete them when the project is over.

<h2 id="transition_to_hana">Transition to S/4HANA</h2>
 Problem 
Upgrades are challenging. Everything from setting up the system to ensuring it performs as expected becomes a daunting task. Significant changes in the system mean that you will make errors. You are also starting fresh, so you do not want to repeat yesterday's mistakes. The good thing is that you know your expected results, and you can improve on the status quo.
 
 Solution 
Leveraging the concepts covered above, you can use this transition as an opportunity to stop banging your head against the wall. This is the perfect time to implement better workflows and improve your system landscape. This approach requires using containers to allow teams access to sandbox systems, implementing CI/CD pipelines, and creating a culture where you encourage automated testing.

<h2 id="validate_processes">Validate Processes</h2>
 Problem 
Your QAS system and PRD system are likely very different. You have probably experienced production issues that you cannot replicate in QAS. Or maybe you want to validate processes in a production replica before you perform them in production! Process validation was previously just wishful thinking but containerized SAP makes that possible.
 
 Solution 
Containerized SAP with the latest production data using a tool like SAP TDMS or third-party solutions makes this a realistic option. Validating processes in an isolated system can help save a lot of effort and headaches and ensure business continuity.

<h2 id="cross_system_compatibility">Cross-system compatibility</h2>
 Problem 
If you're an SAP partner and building solutions, you need the ability to validate that your solutions work on a variety of systems. Validating across systems is a costly and resource-intense process. You might have created your solution on ERP 6.0 Ehp7 on an ASE DB but need to test ERP6.0 Ehp8 on HANA and S/4HANA 2021.
 
 Solution 
You should only run systems when needed. By running containerized versions of SAP, you can achieve this. You can improve the quality of your solutions while not spending your entire budget running systems full-time and starting with configured systems that include data.

 
If your first thought of the headaches listed here is "that sounds nice, but it's too expensive to adopt," you're wrong! The flexibility and system requirements of containerized SAP cloud systems also mean that they can be significantly more affordable than typical setups. So you get better functionality while spending less!

Learn how modern technology can help you solve these issues.

Chances are you have at least one of these pain points in the SAP space. Luckily, we can mitigate or eliminate these issues with modern technology.