Introduction
As a Fiori developer, I have encountered the following issue on several occasions: "Where is the source code of the application located?" Previously, when using SAP WebIDE, it was possible to retrieve the complete code of an application already deployed in SAP Gateway. However, with the latest innovations in Fiori development, this technique no longer works as effectively, and the reference source code is now located in Git. SAP Fiori Tools or UI5 Tooling are NodeJS-based tools that add files to our Fiori application, and these files are not stored in the backend. On the other hand, the Git server will store all this data for us.
For developers coming from the pure SAP/ABAP world, using Git can indeed be unclear or even seem like a daunting task to grasp. I will write a blog post on how to use Git in an SAP On-Premise context.
How to secure the source code?
I've had an experience in my career where, during the development of a Fiori application, a developer would occasionally push without realizing the importance of this action. The application went into production, and a few months later, we were asked to make a modification. Following this change, a regression appeared. My colleague had relied on the incorrect code because I had forgotten to do the push!
When starting to develop Fiori applications with Git, it's common to primarily use the "master/main" branch and misuse commit and push practices. In such cases, the developer deploys the application directly from their own workstation.
Then comes the fundamental question:
How can you ensure that the Git source code matches the version deployed on the SAP system?
The answer lies in the organization of development. Whether you are a single developer or part of a team, it's essential to establish a "software factory" to secure the source code and apply the following rule:
No developer is allowed to deploy into the SAP system! Only the software factory has that privilege.
This rule emphasizes a strict separation of concerns between development and deployment, ensuring that only authorized processes or individuals (in this case, the software factory) have the authority to deploy code to the SAP system. This practice helps maintain control, security, and consistency in the deployment process.
The software factory I mentioned is what we commonly refer to as CI/CD (Continuous Integration Continuous Deployment). I won't go into the details of this tool, as there are websites that can explain it better than I can. However, please keep in mind that this tool automates deployment as soon as an action (such as a Pull Request) is performed on the main branch of the Git repository.
CI/CD is an essential part of modern development workflows, enabling automatic testing and deployment processes, ensuring code quality and consistency, and reducing the risk of deployment issues. If you'd like to discuss CI/CD in more detail or explore any specific aspects of it for your blog post, feel free to provide further information or questions, and I'll be happy to assist.
CI/CD listens to the activities on the "main" branch of the Git repository and initiates a development pipeline as soon as a Pull Request is triggered. The pipeline comprises several steps, but in our scenario, only one step is required, which is the deployment to an SAP On-Premise system.
Which tool choose?
There are indeed many tools available for CI/CD, and SAP offers its tool based on SAP BTP SAP Continuous Integration and Delivery (CI/CD).When I began my research on CI/CD, this service did not initially offer the capability to deploy to an On-Premise server. However, this has since been addressed. Nevertheless, due to the limited documentation on how to configure it, I explored other tools.
I conducted various tests with Azure DevOps, GitLab, GitHub, and CircleCI. One of the reasons I chose these platforms is that, typically, the expertise already exists within the company. Setting up these environments often requires just a single configuration file in the project, making it extremely simple!
Architecture
Once you've mastered the concept, it's essential to focus on the architecture to implement, as security is the key consideration in this type of software factory. There are two possible scenarios: either the CI/CD tool is entirely cloud-based, or it resides within the company's network.
On-Premise setup
This configuration is the simplest to implement. In the diagram below, I could have placed the Git servers On-Premise as well, but the critical point of concern is the CI/CD server, which must have visibility of the SAP DEV server. Typically, this requires firewall rules or network configuration.
Cloud setup
Configurations with cloud-based tools require particular attention to who has access to deploy on the server and thus visibility of the SAP server. While it's possible to create firewall rules to allow requests from various cloud services (e.g., CircleCI or GitHub), this introduces a security vulnerability that can be challenging to manage.
The solution to address this concern is to use a Self-Hosted runner, a server that periodically connects to the cloud CI/CD service to check if there are tasks to perform. If affirmative, it retrieves the commands to execute and the Git clone URL, and it's this server alone that initiates the deployment. As you can see, this server is located on the On-Premise network and can communicate with the SAP server.
This setup enhances security by limiting access to the deployment server and maintaining control over the deployment process.
Indeed, CI/CD providers typically offer a Docker image for the Self-Hosted runner, which simplifies the installation process.
How to deploy?
Now that we have a good understanding of the concepts and architecture, let's discuss how to deploy automatically. With UI5 Tooling, the
npm run deploy command requires specific information, such as:- User and password.
- Transport order.
- Server URL.
- Application-specific details.
All this information is typically stored in the
ui5-deploy.yaml file at the root of the UI5 project. However, for CI/CD usage, we'll need to create a new file and use environment variables to replace some parameters.The advantage of using environment variables is that CI/CD tools can configure them. As a result, the authentication part will be stored in the CI/CD configuration, while the transport order (TR) will be handled for the application in the
.env file.Here's an example of a deployment file (ui5-deploy-cicd.yaml):
# yaml-language-server: $schema=https://sap.github.io/ui5-tooling/schema/ui5.yaml.json
specVersion: "2.5"
metadata:
name: <namespace>.<appname>
type: application
builder:
resources:
excludes:
- /test/**
- /localService/**
customTasks:
- name: deploy-to-abap
afterTask: generateCachebusterInfo
configuration:
ignoreCertError: true
target:
url: https://<server_uri>:<port>;
client: "500"
credentials:
username: env:DEPLOY_USER
password: env:DEPLOY_PASSWORD
app:
name: <application_name>
description: <application_description>
package: <package>
transport: env:TRANSPORT_NO
It's evident that we're utilizing three environment variables:
env:DEPLOY_USER | Stored into CICD server |
env:DEPLOY_PASSWORD | |
env:TRANSPORT_NO | Stored into .env file at the root project |
Example of an environment file:
TRANSPORT_NO = DEVK######Next, you need to add a script for CI/CD in the `package.json` file:
"scripts": {
...
"deploy:cicd": "npm run build && fiori deploy -f -- -y --config ui5-deploy-cicd.yaml && rimraf archive.zip",
...
},Compared to the configuration of a standard deployment, the following parameters have been added:
- -- -y: Disable user interaction
- --failfast, -f: - Throw an error if something goes wrong and exit with a return code != 0.
Conclusion
Through this blog post, I wanted to share my experience in securing SAP Fiori developments. I have often witnessed code losses due to a lack of knowledge about the tools. The real-world scenario shows us that ABAP developers transitioning into web development often apply improper practices, and the software industry is not immune to these mistakes. The CI/CD software factory is the solution to this problem, marking the entrance into the era of continuous development.
I intentionally left out discussing automated testing, a topic closely related to CI/CD, as my primary focus was on promoting a good development practice.
I would be delighted to hear your feedback on your projects related to the implementation of such a system or any other options you have explored to secure your source code.
Enjoy 😉
- SAP Managed Tags:
3 Comments
