It's important to understand how DevOps and CI/CD are related and where they differ. Both are software development methodologies that aim to improve communication and collaboration between different teams involved in building, testing, and deploying software. DevOps emphasizes collaboration between development and operations teams, while CI/CD is a set of practices and tools used to automate the process of building, testing, and deploying software. When used together, these methodologies can help create a seamless workflow that prioritizes collaboration, automation, and continuous feedback throughout the software development process, ultimately helping organizations meet the needs of their end users more effectively. By emphasizing collaboration and automation, DevOps and CI/CD help ensure that software is delivered quickly, reliably, and with the end user in mind.
The SAP ABAP development process historically follows a traditional, sequential approach where different tasks like design, coding, testing, and deployment are completed in isolation with significant manual effort. This traditional approach often results in prolonged development cycles and a lack of collaboration between teams.
For example, a developer may receive a design specification created by a functional consultant, the developer writes the code and then passes off testing to a member of the test team. However, this approach has been transformed in recent years with the adoption of DevOps and CI/CD practices, which emphasize collaboration and continuous feedback throughout the development process.
One of the key ideas behind DevOps is to break down the traditional silos between development and operations teams and create a more efficient and collaborative workflow to meet user needs. The goal of DevOps is to create a culture of shared responsibility for the entire software development life cycle, from planning and development to testing, deployment, and maintenance.
The result is a culture of continuous improvement and a more streamlined software development workflow.
Some key practices of DevOps include:
CI/CD is the acronym for Continuous Integration/Continuous Delivery. CI/CD is a set of practices and tools that automate the process of building, testing and deploying software. The idea behind CI/CD is to create a more efficient and reliable software development workflow by automating as many tasks as possible.
The focus of CI/CD is on the automation of the software delivery process, from code changes to production. By automating tasks like building, testing, and deployment, CI/CD aims to reduce manual effort and improve the overall speed and reliability of the software development process.
CI/CD is a key component of modern software development processes, with many organizations using it to create more efficient and reliable workflows. With CI/CD, developers can spend more time building new features and less time on manual tasks, resulting in faster delivery of high-quality software.
Some key practices of CI/CD include:
When transitioning to CI/CD, it's natural to focus on CI (Continuous Integration) first. This is because code must be integrated before it can be deployed via CD (Continuous Delivery). Nuve Platform follows this natural flow by prioritizing the CI portion of CI/CD. While CD is also possible, the recommended way to deploy code is by leveraging CTS (Change and Transport System) from the DEV → QAS → PRD environments. This process is not only reliable and stable but also auditable, ensuring that the code being deployed meets the necessary quality and compliance standards.
By starting with a strong foundation in CI, Nuve Platform offers a modern software development workflow that emphasizes automation, collaboration, and efficiency. This allows developers to spend more time building new features and improving the software, leading to faster delivery of high-quality software for your end users.
Adopting DevOps practices can bring a range of benefits to SAP development teams, including:
Overall, by making DevOps possible for SAP ERP and S/4HANA, your company can enjoy the benefits of faster, more efficient software development processes, improved quality and security, and better alignment with the needs of the business.
Git is a popular version control system used to manage changes to source code and other files. It's a distributed system that allows multiple developers to work on the same codebase independently and then merge their changes together. This is particularly important in the context of CI, where changes to the codebase must be integrated frequently and reliably.
Using Git, developers can easily track changes to code over time, making it simple to view, revert, or roll back changes as needed. Git also provides tools for branching and merging code, allowing developers to work on different features or fixes in parallel and then merge their changes together when they're ready.
Git is a powerful tool that streamlines the software development process by allowing multiple developers to collaborate on the same codebase while keeping track of changes and making it easy to manage and merge code changes.
To use Git in an SAP system, we leverage abapGit. abapGit is built on top of Git, and it provides a way for ABAP developers to manage their code within the SAP ecosystem using Git.
SAP developers are used to working with a centralized system where all the code is stored on the same system (e.g., DEV), and developers work on the code directly on that system. This approach creates dependencies and bottleneck issues.
In contrast, Git is designed to work with distributed systems, where each developer has an isolated environment. It allows developers to manage and merge changes made by multiple team members. This approach promotes collaboration and can result in more flexibility, speed and agility in the software development process.
Docker is a widely-used containerization platform that helps developers package and runs applications in a consistent and portable way across different environments. With Docker, developers can create lightweight and self-contained containers that include everything needed to run an application, such as the code, dependencies, libraries, and configuration files.
One of the benefits of Docker is that it allows developers to create platform-agnostic containers that can be run on any system that supports Docker, regardless of the underlying operating system or hardware. This makes it easy to move applications between different environments, such as from a developer's laptop to a production server, without having to worry about compatibility issues.
Docker containers are created from an image, which is like a blueprint or template. An image includes all the data, files, dependencies, and configuration settings needed to run the container. You can run multiple containers from the same image, and each container is isolated from other containers.
Docker provides a flexible and efficient way to manage applications and their dependencies, making it easier for developers to focus on writing and testing code rather than managing complex application environments.
SAP is designed for enterprise-level use and typically requires powerful hardware and resources. While it may be difficult to run SAP in a Docker container on a personal computer, running the container on a VM hosted on a hyperscaler is possible. This allows us to leverage most of the benefits of Docker, including creating and refreshing a system in minutes.
Docker images serve as templates, and with them, we can create images that include production-quality data. By doing so, we can perform the cycle of code-test-debug-repeat on an isolated system rather than on a DEV system with little or no data. This gives us an unprecedented level of control and testing capability.
Static analysis is a tool that helps developers find mistakes or problems in their code before running it. You can think of checking your homework before submitting it to ensure everything is correct.
When you write a program, you give the computer a set of instructions to follow. These instructions need to be written in a specific way, or the program might not work properly. Static analysis acts like a helper that checks the instructions to ensure they are written correctly and follow the rules.
The tool that performs the checks is called a linter. A linter interprets source code to identify potential errors, bugs, or issues that can be detected through static analysis. Linters can be used for a wide range of programming languages and can help improve code quality and maintainability by identifying issues before the code is executed.
Nuve recommends abaplint for ABAP development. It can be easily integrated into CI pipelines to automatically check any ABAP code that is committed. Think of it as a robotic helper that ensures your code conforms to your company's guidelines and identifies potential errors, bugs, or issues before you run it.
Automated testing is a process that uses software tools and scripts to run tests on an application or system automatically without the need for human intervention. This allows developers to quickly and efficiently test their code for bugs, errors, and other issues that could impact the application's performance or functionality.
To conduct automated testing, developers use testing frameworks and tools that can simulate user interactions, generate input data, and verify the output of the application. This allows for a wide range of tests, such as unit tests, integration tests, and end-to-end tests, to be performed with ease.
SAP has several automated testing frameworks available, but one key requirement of testing is repeatability. For instance, if you're testing the conversion of sales orders to deliveries, you need to know the initial state of the order and the expected delivery result. However, setting up the initial test data can be a manual and time-consuming process, making it challenging to ensure repeatability.
That's where Docker comes in as a "best practice" for automated testing. By using Docker, you get a known initial state that can easily be repeated. This helps ensure that your automated tests are accurate and reliable, saving you time and effort.
Unit testing is a type of automated testing that focuses on testing individual components or units of a software application in isolation. These tests are usually small and targeted, designed to ensure that a specific unit of code (like a function or method) meets the requirements and functions as expected.
To conduct unit testing, developers use a unit testing framework that provides tools and utilities for writing and running tests. The framework enables developers to write test cases that check specific inputs and outputs for each unit of code being tested. Once the tests are written, they can be run automatically to verify that the code is working as intended.
ABAP Unit is an excellent testing framework for unit tests in ABAP. It provides a variety of testing options, including the ability to simulate user interactions and test database access. It also provides a report of the test results and the ability to automatically execute the tests as part of a continuous integration process.
By incorporating ABAP Unit into your CI pipeline, you can make sure that code passes tests before merging a feature branch with the main branch.
The traditional SAP landscape typically includes the following tiers:
One of the main challenges with the shared development tier in the traditional SAP landscape is the potential for conflicts. Because the development tier is shared, multiple developers may be working on the same objects or components within the codebase, which can lead to conflicts and version control issues. Depending on the scope of the change or the project, this can lead to a significant delay in moving a feature from DEV to PRD.
Other challenges with the shared development tier may include:
An n+1 SAP landscape is an expansion of the traditional SAP landscape model that provides a dedicated environment for testing new SAP applications or upgrades. With n+1, an additional system is added to the existing landscape, which acts as a testing or staging environment. The new system is usually set up to be similar to the production environment. This helps minimize the risk of issues or downtime when importing transports to the production environment and ensures the quality and reliability of SAP applications and upgrades.
Typically, the n+1 SAP landscape is a requirement to overcome the limitations of a shared environment. It allows companies to overcome the challenge of too many developers sharing a system and allows for the implementation of multi projects in parallel.
Traditional methods for setting up and maintaining an additional system can be expensive, as it requires additional hardware, software, and infrastructure. Typically, when this landscape is set up, the systems will run constantly for years.
The setup also requires significant time and effort from Basis and administrators, which can impact their ability to work on other projects or tasks.
Nuve Platform enables companies to implement a modern system landscape that enables DevOps for SAP. This is achieved through powerful automation that eliminates any manual effort required to create SAP systems. This revolutionary advancement allows each developer to have an ephemeral SAP system so they can develop in isolation. The transformation from traditional development to DevOps solves the challenges with the traditional SAP landscape and n+1 landscape.
Of course, this paradigm shift requires us to add new tools to our SAP developer toolbox. The good thing is that all of the new tools are used by millions of developers around the world, and best practices are well established. It's very likely you already have experts within your company, any non-SAP developers.
This document and supplemental guides are designed to walk you through the journey of introducing DevOps to your organization. Nuve provides organizations with the tools and resources they need to manage the complexity of SAP development while improving collaboration and communication among stakeholders. Soon after your journey begins, you will improve efficiency and reduce the risk of errors and conflicts in your development process.
To enable DevOps, we leverage Nuve Platform and GitHub Actions and add CI pipelines outside of the traditional SAP Landscape. This development workflow is designed to avoid disrupting your business operations and has a low risk of deployment. We help transition your developers to a modern workflow in a gradual and easy way. Developers work on specific repositories on a Nuve system in isolation and use GitHub Actions outside of the traditional landscape. Once a repository is ready, the code can be easily pulled into the Development system (DEV) and added to a transport request. The transport request can then move up the landscape with your existing transport management process. Our landscape makes managing your development workflow more flexible and efficient without causing any challenges for your business.
Starting with a basic pipeline that's easier to manage is a good way to ease into CI. While we have a best practices pipeline available, we understand that beginning with such a comprehensive approach can be overwhelming.
The basic pipeline helps you get familiar with our tools and practices and empowers you to gradually work your way up to a more complete process as you become more comfortable. Our goal is to make the process of setting up and managing software changes as manageable and efficient as possible, whether you're using a basic pipeline or the best practices pipeline.
Git uses repositories (or repo for short) to store development objects. A repo is similar to SAP packages. Both packages and repositories provide a way to organize and manage changes to objects. While the specifics of how they are used may differ, the overall concepts are similar in nature.
In fact, they're so similar that abapGit matches an SAP package to a Git repo one-to-one. So as a prerequisite, you need to identify a package that will be initialized as a git repo to be used in the CI pipeline.
When you have identified the SAP package that you want to add to your CI pipeline, the next step is to initialize the package in abapGit. This is a one-time setup required to enable you to manage the package using abapGit.
The initialization process involves creating a new repository in GitHub, configuring it for use with abapGit, and then linking it to the SAP package. Once this is complete, you will be able to use abapGit to manage the package and integrate it into the CI pipeline.
Overall, initializing a package in abapGit is a relatively straightforward process. Once it is complete, it provides a powerful tool for managing SAP packages as repositories and streamlining the development process.
After you identify a package for CI, you need to initialize it in abapGit. You can follow the steps outlined in the abapGit Guide: Moving a Package into Git.
There's no one-size-fits-all approach to choosing a repository to start with. It's important to keep in mind that when we use the term "repository," we're referring to an SAP package. That said, there are a few common characteristics to consider when selecting your first repository to make it easier to transition to CI.
It's generally a good practice to start by outlining your key challenges and then identifying some quantifiable objectives. By doing so, you can work backward to determine the appropriate package to use.
Alternatively, if there's a logical grouping of objects within a package that makes sense to isolate into a single repository, that is also a viable option. Keep in mind you need to carefully consider the dependencies and impact of moving objects between packages, as it can have implications for other objects that depend on those objects.
When selecting an initial repository, look for these elements to ensure a smooth transition to CI.
As SAP developers, it's essential that we stay up-to-date with the latest technologies and methodologies in order to deliver high-quality software. Although change can sometimes be challenging, there are some basic concepts of Git that can help us unlock the full potential of CI pipelines.
Getting started with Git is easier than you might think. By creating a GitHub account and setting up your first repository, you can begin using abapGit to manage your ABAP code and collaborate with other developers. And as you become more comfortable with Git, you'll have the opportunity to explore more advanced features and continue expanding your knowledge.
So don't let the fear of change hold you back. With just these basics, you can start using GitHub and abapGit to streamline your development process, collaborate more effectively, and deliver better software faster.
Developers need to sign up for a GitHub account. Note: it’s likely your organization already uses GitHub and has Team or Enterprise account.
Once you have a GitHub account, setting up your repo only takes a few minutes. The following guide walks you through the necessary steps to set up your first repo.
Now you're to get your CI pipeline going! To help you get started, we've outlined the steps you can follow to ensure your changes are properly integrated into your CI pipeline. By following these steps, you can make sure that your package is always up-to-date, well-tested, and ready for deployment.
Developer receives a requirement to implement a change or feature.
Developer and reviewer collaborate to merge code
Tester, Developer, and Ops collaborate to deploy using CTS
Although the change may appear significant at first glance, rest assured that the updated steps are straightforward to execute and require minimal effort. The benefits of adopting this new pipeline are substantial and will positively impact your development. Once implemented, you will undoubtedly appreciate the improvements and wonder why it was ever done differently.
When you're ready to take your DevOps approach to the next level, we have a comprehensive best practices pipeline that can help you achieve even more benefits. By adopting this pipeline, you can further optimize your workflow, enhance collaboration, and improve the overall quality of your software development process. It's important to find a pace that is suitable for your organization when moving toward this comprehensive pipeline. So set your sights on this goal and start moving towards it to unlock the full potential of DevOps practices.
There are two recommended additions to the initial steps of identifying a package and initializing its repository.
There are two recommended additions to the initial setup of GitHub Actions
If you haven't already done so, we strongly recommend implementing the automatic creation of transport of copies. This practice helps ensure that the number of transports is kept in sync with the number of approved PRs, which in turn reduces the risk of errors when importing transports to production due to missing dependencies.
As SAP developers, we're all too familiar (and frustrated) with object locks, but there's a better way to manage source code. Git has become the industry standard for source code management, as evidenced by the fact that over 90% of developers worldwide use it, according to the 2021 Stack Overflow Developer Survey. As SAP developers, we should also be using Git, specifically abapGit for SAP.
The question is, why haven't we made the switch? One reason is that Git is designed for distributed development, which wasn't possible until we enabled it at Nuve Platform. It's worth noting that not all SAP objects are currently supported by Git. However, there is a way to add support for any object, and we'll explore this topic in more detail.
Nonetheless, it's important that we adopt best practices for source code management in SAP. In this section, we'll cover these practices and explain why Git and abapGit are the tools of choice for SAP developers.
abapGit is a git client for ABAP. It allows us to interact directly with a Git server (e.g., GitHub) from SAP.
To fully understand the benefits of Git, it's important to understand the challenges of source code management in a traditional SAP landscape. Imagine you're running an e-commerce site and need to make updates to a class that retrieves order history in a shared DEV system. While one developer is working on a feature to allow formatting dates based on the user's location, another developer needs to work on a feature that displays order history by a specific sales organization. Both features are highly requested by customers, but working on them in parallel increases risk and adds complexity to the testing cycle. Alternatively, waiting until the first feature is complete slows progress on fulfilling business requirements.
The root of this problem is the need for developers to share a single development environment. This is where Nuve and abapGit come in. Nuve and abapGit enable distributed development, allowing developers to work on isolated systems using separate branches and merging their changes later, reducing risk and increasing efficiency. abapGit enables developers to work on different features independently while still sharing a common codebase. This leads to faster development cycles and, ultimately, better business outcomes.
Git uses repositories to store development objects, which are similar to SAP packages in their function to organize and manage changes to objects. abapGit matches an SAP package to a Git repo one-to-one, so a package needs to be initialized as a Git repo for the CI pipeline. Overall, both Git repos and SAP packages share similar concepts for organizing objects.
While this documentation does not cover advanced topics, we can provide you with the basics of using abapGit. However, if you want to learn more advanced topics about abapGit or Git, we recommend referring to the abapGit documentation and the git-scm Pro Git book.
With the fundamental concepts of Git, we can accomplish almost everything required for our CI pipelines. Below, we outline the necessary steps to get started.
Match the branch rules below for repositories used with abapGit and the CI pipeline.
It's possible to add support for new objects that aren't currently supported by abapGit.
You can submit an issue request to the abapGit repository if you're a business user. If you're a Nuve Platform or abaplint.app customer and need to prioritize support for the new object, you can email email@example.com or submit a support ticket via your admin console.
If you're a developer interested in contributing to the abapGit open-source project, you can submit a PR. For technical details on how to implement new object types, refer to the abapGit documentation on serializers at docs.abapgit.org/development/serializers.html.
Open source has been a powerful movement for over two decades and has become ubiquitous in the technology landscape. It's not going anywhere, so if you haven't already, it's important to embrace it. However, keep some key considerations in mind when evaluating open-source tools. Your broader IT and legal departments likely have extensive experience and policies with open source, so it's a good idea to leverage their knowledge and expertise to become more informed.
One option for added security is to follow best practices for building a secure and stable fork of an open-source project. Below are practical steps you can take to ensure that your fork is secure and reliable. Whether you're new to forking open source projects or a seasoned veteran, these steps will help you build a fork that meets your organization's needs while minimizing risks and vulnerabilities.
abapGit doesn't support all types of objects in SAP, but you can still use it alongside traditional SAP transports. If you need to move an unsupported object to your central SAP landscape, you can add it to a transport and migrate it as you would with any other SAP transport.
Be aware that this method carries some risks. If the object already exists in the traditional SAP landscape's DEV system, importing the transport may overwrite changes. This approach is best for new objects that aren't yet supported by abapGit.
In some cases, when making changes that are not supported by abapGit, it may be necessary to copy and paste the object to the development system manually. This process is similar to what some developers and SAP users do when working in a sandbox environment.
However, it's important to note that abapGit is the recommended and preferred approach for transporting objects between systems whenever possible. This ensures consistency and reduces the risk of errors and inconsistencies that may arise from manual copying and pasting.
Code transparency refers to the practice of making code publicly accessible and visible to others, either within an organization or to the broader community. There are several benefits to code transparency:
As a developer, feeling anxious about code reviews is normal, especially when you're new to the process or working on a complex project. But it's important to remember that code reviews aim not to find faults or criticize but to help each other grow and improve as developers. By reviewing each other's work, we can share our expertise and institutional knowledge, which ultimately makes us a stronger and more effective team. Don't lose sight of the goal; code reviews aim to improve collaboration and learn from each other.
As SAP professionals, we're familiar with access management. This will also extend to any new methods of source code management that we apply. Fortunately, these new methods have been proven to be secure. With that said, you should always keep the following in mind.
There can be several cultural challenges when adopting Git, particularly if a company is not accustomed to using version control systems or collaborating on code development. Some of these challenges include: