Primer on the Fundamentals of DevOps

---

P.1 Overview of DevOps and CI/CD

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.

P.1.1 DevOps

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:

• Continuous feedback and communication between teams and end users
• Automated testing and deployment
• Continuous monitoring and feedback on application performance
• Infrastructure as code
• Shared ownership of the entire software development life cycle

P.1.2 CI/CD

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:

• Continuous integration of code changes
• Automated testing of code changes
• Use of version control systems
• Continuous delivery of code changes to production
• Automation of build and deployment processes

P.2 Benefits of DevOps for SAP ERP and S/4HANA

Adopting DevOps practices can bring a range of benefits to SAP development teams, including:

• Faster time-to-market: DevOps enables faster and more frequent releases of software, allowing SAP development teams to deliver new features and functionality to end users more quickly.

• Improved quality: By automating testing and deployment processes, DevOps can help reduce errors and bugs in SAP applications, leading to improved quality and reliability.

• Increased agility: DevOps enables SAP development teams to respond more quickly to changing business requirements and market conditions, allowing them to stay competitive in a rapidly evolving landscape.

• Better collaboration: DevOps promotes closer collaboration and communication between development, operations, and other teams involved in the software development process, helping to break down silos and improve overall team efficiency and effectiveness.

• Enhanced security: By integrating security considerations into the software development process from the beginning, DevOps can help improve the security and resilience of SAP applications, reducing the risk of cyber attacks and data breaches.

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.

P.3 Key concepts and terminology

P.3.1 Git

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.

P.3.2 Docker

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.

P.3.3 Static Analysis

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.

P.3.4 Automated Testing

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.

P.3.5 Unit Tests

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.

Module 1: Setup CI Pipelines with Nuve

---

Overview of the SAP landscape on Nuve

Traditional SAP Landscape

The traditional SAP landscape typically includes the following tiers:

1. Development (DEV): DEV is where developers create and modify SAP applications. This system is also used for testing and debugging SAP code by developers. However, developers often face limitations such as poor quality data or no data, slow access times, and object locks due to shared resources. These limitations can make development more challenging and time-consuming.

2. Quality Assurance System (QAS): QAS is where developers and testers ensure that new or modified SAP applications are working correctly. The QAS environment is supposed to resemble the production environment closely. However, in most companies, DEV lacks data, which means that testing is done solely in QAS. This requires developers to code in DEV and quickly move their code to QAS for testing and debugging. As a result, a typical QAS environment quickly becomes polluted and does not resemble the production environment.

3. Production (PRD): PRD is where SAP applications are actually used by end-users. It is the final stage in the development cycle and includes high-performance servers and other hardware to ensure that the applications run smoothly and efficiently. In addition to hardware, the production tier also includes tools and systems for managing and monitoring the applications to ensure that they are operating as expected. It is crucial that everything runs smoothly in the production environment, as any issues or downtime can significantly impact end-users and the business as a whole.

Challenges with Traditional SAP Landscape

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:

1. Version control issues: When multiple developers are working on the same codebase, it can be difficult to track changes and manage version control, which can lead to issues and conflicts when trying to release transports and importing to PRD.

2. Slowdowns and bottlenecks: Shared DEV and QAS systems can lead to slowdowns and bottlenecks in the development process, as developers may need to wait for access to certain resources or components.

3. Quality control: It is challenging to ensure consistent coding practices and standards when multiple developers are changing the same code in a single transport, which can impact the overall quality and maintainability of the code.

4. Testing issues: Because multiple developers may be working on the same codebase, it can be challenging to ensure that testing is comprehensive and that all changes are thoroughly tested.

n+1 Landscape

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.

Challenges with n+1 Landscape

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 Landscape

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.

Setting up your SAP system for DevOps

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.

Basic Pipeline for DevOps in SAP

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.

🔑 Prerequisite: Identify a Package and Initialize its Repository

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.

Recommendations for Initial Repository

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.

• Most objects are related

• The package focuses on a logical work unit that follows Conway's Law

• Primarily contains ABAP or development objects (avoid excessive forms)

🔑 Prerequisite: Hello, GitHub

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.

Basic Git Concepts

• Clone a repository
• Push the changes to the remote repository
• Create a new branch for your changes or feature
• Add and commit the changes from your Nuve system
• Create a pull request (PR) on GitHub

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.

Set up your GitHub repository.

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.

Basic CI Pipeline

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.

1. Developer receives a requirement to implement a change or feature.

   1. Create an ephemeral Nuve instance
   2. Clone the repo on abapGit
   3. Implement code changes, test, and debug if necessary
   4. Commit and push the changes to a new branch using abapGit

2. Developer and reviewer collaborate to merge code

   1. On githhub.com , create a new Pull Request (PR) from the repo, add a description, and list test steps

   2. Someone on your team is automatically assigned to review the PR. If the reviewer requests changes, the developer is notified and goes back to step 1, part c

3. Tester, Developer, and Ops collaborate to deploy using CTS

   1. The PR is added to a transport of copies that is automatically released and migrated to QAS (optional but recommended)

   2. The test team runs integration tests. If the integration tests fail, the developer is notified and goes back to step 1, part c

   3. The PR is added to a regular transport that is automatically released and migrated to QAS

   4. Follow your existing process to import to production

Congratulations on completing your first pipeline!

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.

Best Practices: CI Pipeline

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.

Best Practices: Identify a Package and Initialize its Repository

There are two recommended additions to the initial steps of identifying a package and initializing its repository.

1. To ensure that your code adheres to your organization's guidelines and checks for dependencies, add an abaplint configuration file.

2. To maintain code quality and compliance, configure the main branch rules to require at least one code review and require passing status checks before merging changes.

Best Practices: GitHub Actions

There are two recommended additions to the initial setup of GitHub Actions

1. Run abaplint via GitHub Actions to ensure your code adheres to your organization's guidelines. If abaplint fails, the developer will be notified to address the issues before proceeding.

2. Automate the execution of ABAP Unit tests using an ephemeral Nuve instance created by Actions. If the ABAP unit tests fail, the developer will receive a notification to address the issues before continuing.

Deploy using CTS

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.

Module 2: Source Code Management for SAP

---

Overview of Source Code Management

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.

Problem with SAP Source Code Management

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.

abapGit for SAP

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.

Developer Basic Git Concepts Explained

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.

1. Clone Repositories: To get the entire codebase of a repository installed in a system where it previously didn't exist, you can use the "Clone" command in abapGit. This command is split into two steps - first, you clone the repository and then pull it. When you clone a repo, it will default to the main branch.

2. Push and Pull: After cloning a repository, you'll need to add your changes to the codebase by "pushing" them to your Git repository. To get the latest changes from other developers on the codebase, you'll need to "pull" them. The push command has two steps - first, you stage your changes and then commit them to your Git repository. If other developers have made changes to the remote repository (likely the main branch), you'll need to update your local version of the code by doing a pull.

3. Branches: Git uses branches to manage different versions of the code. Each developer can create their own branch to work on a specific feature or bug fix and then merge their changes back into the main branch when they're ready. When you push your changes, you should push them to a branch that belongs to you or a branch you have permission to push to. abapGit allows you to do this on your first push or before you make any changes. If you forget this, branch protection rules prevent you from pushing to the main branch.

4. Commits: In Git, a commit is a record of changes made to the code. Every time you push changes to your Git repository, Git creates a commit. You will likely have several commits for each branch. You are required to add a short and descriptive message about the changes each time you commit.

5. Create a Pull Request (PR): Once you're done with your development, you'll need to create a pull request. This is done from the branch that you pushed all your commits to. The pull request will be used for peer review, and all the code will be checked against abaplint. The unit tests will also automatically run, and the results will be checked.

Branch Rules

Match the branch rules below for repositories used with abapGit and the CI pipeline.

Support for New Object Types

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 support@nuveplatform.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.

Embracing Open Source: What You Need to Know

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.

1. Intellectual property considerations: Open source licenses come in various types, with the most permissive being the MIT License. This license is designed to remove any concerns about intellectual property. abapGit is licensed under the MIT License by design, which means you can use and modify the code as needed without worrying about any legal issues related to intellectual property.

2. Control and ownership: Open source projects can change quickly, and any negative changes can range from breaking some functionality to the project no longer being supported. If a tool provides significant value to your organization, being actively involved and providing support may be worthwhile. Alternatively, with a permissive license like the MIT License, you can continue to use and maintain an open-source project, even for internal use only, without any obligation to contribute to the project or provide support.

3. Security and reliability: The security and reliability of any software should always be taken seriously, whether open source or not. One of the great benefits of open source is that the code is available for anyone to read and alert the public of vulnerabilities. Using projects with a diverse and active community of contributors is important. abapGit has a community of over 150 contributors worldwide who are active and vigilant in maintaining the codebase. For additional information on building a secure and stable fork, please refer to the section "Secure Approach to Building a Stable Fork."

Secure Approach to Building a Stable Fork

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.

1. Start with a Stable Base: When forking the abapGit repository, starting with a stable and secure base is important. Choose a point in the repository's history where you are confident it's stable and secure, and build your fork from there. This will help ensure that your fork is not vulnerable to known security issues and allows you to take advantage of the latest features.

2. Update Strategy: It's important to keep your fork up-to-date with the latest patches and updates from the original abapGit repository. This will help ensure that your fork is not vulnerable to known security issues. Establish guidelines on update frequency and include the updates in your CI pipelines to ensure you do not break dependencies.

3. Monitor for Vulnerabilities: In addition to keeping your fork up-to-date, it's important to monitor for vulnerabilities and security issues that may arise in the abapGit repository you're forking. Stay on top of security bulletins and alerts, and consider using automated tools to scan your repos for vulnerabilities. This will help you catch potential issues early on and prevent them from becoming bigger problems down the line.

4. Engage with the Community: Finally, don't be afraid to engage with the abapGit community. Participate in discussions on the abapGit Slack channel, contribute back to the abapGit repository where possible, and collaborate with other users to help ensure the long-term security and stability of the project. The more engaged and active the community is, the stronger and more secure the project will be.

Export & Import Transports

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.

Export from Source System

1. Go to SE10 and click Display
2. Release the transports you want to export
3. Go to t-code CG3Y

4. Download the transports

   • Cofile from \sapmnt\trans\cofiles\K TRANSPORT_NUMBER.SID

   • Data from \sapmnt\trans\data\R TRANSPORT_NUMBER.SID

Import into Target System

1. Navigate to transaction CG3Z

2. Upload the files to the corresponding path

   • K TRANSPORT_NUMBER.SID in \sapmnt\trans\cofiles

   • R TRANSPORT_NUMBER.SID in \sapmnt\trans\data

3. Navigate to transaction "STMS"

4. Select Extras -> Other requests -> Add and select the transport you just uploaded.

Manual Copy & Paste

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

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:

Benefits of Code Transparency

1. Collaboration: By making code transparent, developers can more easily collaborate on code changes and share knowledge and best practices. This can improve the quality and reliability of the code, as well as reduce the time and effort required for development.

2. Code review: Making code transparent allows for more effective code review, as other developers can review and provide feedback on code changes. This can help identify potential issues or bugs before they become a problem and can also provide opportunities for learning and knowledge-sharing.

3. Accountability: Code transparency can help promote accountability and responsibility, as developers are more likely to take ownership of their code and be held accountable for any issues or bugs.

4. Community building: Making code transparent can help to build a sense of community among developers, as it encourages collaboration, knowledge-sharing, and support.

5. Innovation: Code transparency can also help to drive innovation, as it provides opportunities for developers to build on existing code and develop new applications and solutions.

Overcoming Review Anxiety

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.

Proper Access Management

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.

1. Intellectual property concerns: Protecting intellectual property is critical for organizations, and it's important to keep proprietary code private and confidential. If the code includes proprietary or confidential information, it should not be made public. Before making any code public, organizations should carefully consider what information is included and take steps to ensure that sensitive information is protected. By being mindful of intellectual property concerns and taking steps to safeguard sensitive information, organizations can protect their valuable assets and maintain the trust of their stakeholders.

2. Security risks: Security is a critical concern when it comes to protecting an organization's code. Organizations should implement appropriate security measures like access controls, processes, and other security features to safeguard their code from potential threats. This helps to protect the code from unauthorized access or modification by malicious actors who may try to steal or misuse the code. By taking proactive steps to secure their code, organizations can minimize the risk of security breaches and protect the integrity of their software.

3. Limited Access: It's important to limit access to SAP code on GitHub only to those developers who need it, just as we would set profile restrictions in SAP. This helps to ensure that the code is secure and that there is less risk of it being accessed or modified by unauthorized parties. When granting access, it's also important to be mindful of third-party developers and to carefully vet them before giving them access to any sensitive code. By being cautious and selective with access, we can help protect our SAP code's integrity and security.

Cultural Challenges

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:

1. Resistance to change: Some developers may be resistant to adopting Git, particularly if they are used to working in a certain way or with certain tools. It is important to provide training and support to help developers understand the benefits of GitHub and how to use it effectively.

2. Lack of collaboration: If developers are used to working in isolation, they may not be comfortable with the idea of collaborating on code development with others. It is important to foster a culture of collaboration and encourage developers to work together to achieve common goals.

3. Fear of exposure: Developers may be hesitant to make their code transparent, particularly if they are concerned about the quality of their code or the potential for criticism or negative feedback. Creating a supportive environment where developers feel comfortable sharing their code and receiving feedback is important.

4. Communication challenges: When using Git, it is important to establish clear communication channels and guidelines to ensure that developers are able to collaborate effectively and provide feedback on code changes.

5. Lack of trust: Adopting Git requires trust among developers, particularly if they are working on code critical to the organization. Establishing clear guidelines and procedures for code review and approval is important to ensure that code changes are thoroughly vetted and meet the organization's standards.