It’s been a strange year, one in which we’ve shifted from working at the office to working from home. During my lunch break, I like to get some fresh air by going for a walk outside. It’s nice to spend some time outdoors instead of staying indoors all day long. During these walks, I see a lot of different things. And strangely enough, these things inspire me. For example, road workers, who are building the streets we use every day. A lot of stones have to be placed in the right position. That takes quite some time. One by one, those stones have to be laid in the right place, and before any of that, the surface has to be prepared. The area has to be even and level. Looking at it from a distance, it seems like those guys are repeating the same task over and over again. It’s also crucial that the quality of their work remains consistent. The repetitive nature of their work must be flawless. I’m sure they have quality checks—usually performed by someone else—to ensure everything is in order.
A few streets further on, I see a man mowing the lawn, walking back and forth to mow the entire area. He looks a bit bored—he’s clearly not enjoying this task. You can also see that a lot of manual labor is required to get the job done. No harm done—it’s outdoors, and if the weather is nice, it can be relaxing. Still, there’s quite a bit of repetition in the tasks here as well.
Improvement
Above are some examples of repetitive and labor-intensive work that can be improved. Let’s take stoneworkers as an example; I’ve seen machines that lay stones automatically. Or, in the other example, a robotic lawn mower would be a huge help here. Machines are ideal for repetitive tasks. Another advantage of machines is that they perform their work so precisely that quality checks are rarely necessary.
Analogy
In your day-to-day work, there are also repetitive tasks that can easily be automated. For example, the sales order process. During that process, someone reads various emails to determine what data needs to be entered into a new sales order screen. They also need to validate some of the data before entering it. This process could easily be automated using robotic process automation. The robot validates and enters the data. You can also configure the user interface and application so that user entries are at least initially validated automatically. This is one of the areas of software where automation and process optimization play a role. Automation can also be viewed as replacing a human performing a task with a piece of software. Of course, every process needs a start, an end, a trigger, and usually involves one or more people who are involved in certain parts of the process.
Software Development
Also, software development itself is a process. A developer builds something, tests it, and continues development in their local environment. After some iterations, the software needs to be deployed to a development environment. Before this deployment, a build of the software is required. This code must be stored in a software repository. All of these are steps in the development process. If we view Fiori development (creating SAPUI5 applications) as a process, we see that the development process involves building, testing, deploying, and code versioning. At every customer site, these basic elements are hopefully in place. While all aspects are likely present, many customers still require manual intervention to perform a build, deployment, or transport. A visual diagram of the existing process—including start and end points, triggers, and different actors—is very helpful in clarifying which steps need to be taken next. It also highlights where human intervention is required and, therefore, where time needs to be spent. Additionally, consider peer reviews and code reviews.
When you run this and visualize your current process, you may see various steps that don’t take much time. However, you still need to consider them and execute all the steps in the correct order. Generating preload files, minification, deployment, and uploading your code are some of these steps. They are part of the build process. After this, you can clearly see which actor is doing what, and what is done by a “system.”
Optimize
Now, think about it again: since all these tasks are part of your process, what would you optimize, and how would you ideally start the process? Could a code commit to the code repository serve as a trigger? What could be automated—started and executed automatically—and what would trigger it? By doing this, you’ll see the optimizations. Do you see the benefits?
Implement
Now we know what we want, but how do we go about it? We do have a code repository such as Git, BitBucket, GitLab, GitHub, and the like. We also have tools for building, such as SAP build tools and, previously, Grunt scripting. We can deploy via our WebIDE or Business Application Studio, or—in a very old-fashioned way—via Eclipse. All of these require a human to take the first step to trigger them.
To turn this into a process, we need tools to help us do that. Examples include Bamboo, Jenkins, and GitLab—server setups that can execute various tasks sequentially, triggered by a specific event. In GitLab, for example, you can set up pipelines where you either process a chain of actions sequentially (continuing only if successful) or in parallel. It does take some time to set up, but it’s worth it to add your build as a step in the pipeline. Triggered by a code push, this initiates the build; after that, the software is automatically deployed (another step) to a specified development environment. These are all examples of recurring actions. By incorporating these actions into the pipeline, we now only need to push the code to the source control system, and everything else happens automatically.
Extend it!
Nice, but not very helpful, right? A well-known concept in software development is Continuous Integration and Continuous Delivery. Let’s start with continuous integration—we always want to know if our code “works” and still integrates with other modules. Let’s explore some continuous integration topics: If our pipeline runs smoothly, we might want to add more steps to it. We used to have a manual task for code review. What about code validation? Validating whether the code is written correctly—no syntax errors, limiting the length of functions, no duplicate code, and so on. In this case, consider tools like ESLint, JSLint, or Sonar as examples that can help here. Let’s add this as well. We can even make steps dependent on our process—for example, we can deploy only when there are no ESLint errors and notify the developer of the result. This standardizes the process and sets the bar for high-quality coding.
Test
Is that all? Nope, we also need to test our applications. This could mainly be done through a lot of manual testing, and here, too, the same question arises: can we automate it? It turns out you certainly can! Robot Framework, jUnit, qUnit, OPA5, and Uiveri5, together with a WebDriver, are all frameworks that can help you with automated testing—whether it’s unit, functional, integration, or end-to-end testing. If we add these OPA5 tests, for example, to our pipeline, we could run a standard set of 10 regression tests to ensure the app still performs its basic functions or to verify that the code is still working properly and that each function behaves as expected. This is valuable because it constantly verifies that our code doesn’t break the app’s functionality and can therefore be deployed to a production environment later. This is another important step in continuous integration. Now the system continuously verifies that our codebase still represents a working app. This is automatically checked with every change to the codebase. Once we’ve added this to our pipeline, we truly have a full-fledged process, triggered by just a single code push! It builds, validates, tests, and deploys our code. Of course, it also requires change management, since it’s obviously best if all developers adopt this process and stop performing manual deployments to ensure quality.
As you can see, the concept of continuous integration and continuous deployment aligns very well with what we’ve just achieved. By performing continuous testing after every code change, we achieve continuous integration. The other aspect is continuous deployment. Since we are already able to deploy within our pipeline steps, we only need to connect to a transport management system and maintain control over the process (without being dependent on monthly release cycles) to achieve continuous deployment.
Closure
As you can see in many examples—in everyday life, as well as in software and software development—there are processes that can be optimized and further automated. We’ve identified which steps can be automated and how to achieve continuous integration, which will improve the quality of releases and reduce the time developers spend on regression testing. All of these factors contribute to delivering software to users faster and sooner. We’ve also learned what continuous deployment is and that it’s very important to be able to release at any time, which means end users can start using new features sooner. Setting up an improved development process takes some time, but it’s definitely worth the effort.
Are you also considering setting up a pipeline like this? But not sure where to start? Do you need help setting up your CI/CD system or with specific tasks within it? Feel free to contact us!
