Skip to Content
Technical Articles
Author's profile photo Nuno Pereira

SAP CPI: CI/CD from zero to hero – Code Review

This blog is part of a blog series, so you can find the first page here ( This is the agenda we’re following:

Code Review

Code Review is most likely your last quality gate before releasing and transporting your developments to the next environments, so I don’t need to convince you on the importance that such step has on the quality of your interfaces. Despite we do many of our checks automatically via CPI Lint saving time to our reviewers, there are things that were not yet automated via CPI lint rules due to the lack of time. There are also topics that can’t be automated easily and need some common sense and manual checking.


Taken from

Code Review – How it started

Since day one that we have code review, but initially it was a quite informal (despite mandatory) task. A developer would invite another one, explain briefly the code steps, the reviewer could ask some questions or provide some inputs, but in the end, almost always the code was reviewed without major changes. If that sounds suspicious to you, it also sounded suspicious to me… After some reflections I got into some conclusions on why I consider this a flawed approach:

  1. Code was being reviewed on the fly, with little buffer for reviewer intervention or even the proper time to digest and think about alternatives
  2. There was no standard check list in place on what to review, so it was really up to the reviewer to have the imagination to think about problems or scenarios with the code being reviewed
  3. Despite there’s no proof, I highly suspect that some reviewers got intimidated by providing feedback on the spot to the producer of the code

We had a brainstorming session about this, and based on previous reviews plus the experience of the group we came with a check list of mandatory checks to review (this would solve step 2 above).

Another outcome was that we would invest on a code review process that would be transversal to both our teams (CPI team using Gitea and Biztalk team using TFS).

Code Review – How it evolved

There are many code review tools available in the market, some of them integrated into git itself, meaning you could do a pull request in order to merge your changes into the main branch and with that a code review is done to validate if your branch can be merged into main stable branch. After thinking about using pull requests as a code review approach, we saw no real benefit since we wouldn’t do anything with the main branch after integrating the pull request. Our synchronization from SAP Cloud Integration (CI) to GIT only happens in that specific direction, we don’t synchronize back from GIT to SAP CI because that would bring additional problems to solve (locks, conflicts, no more single source of truth, etc).

Someone from the team suggested Fisheye+Crucible and after an evaluation and a POC, everyone enjoyed it and we adopted it for both teams.

Short intro to Fisheye

This is a tool to provide searching and diff capabilities to your git repository from the crucible+fisheye dashboard. It works by synchronizing your git repository into a local fisheye repository allowing you to have a single central place for all your source code repositories (Gitea+TFS)


List of synced repositories view on fisheye+crucible

Short intro to Crucible

This is the tool to do the code review process itself. It has the concept of projects that would serve as aggregators (you create a review for a project). You could group code that would make sense to review together coming from different sources. We would like to avoid this complexity, so we make it very transparent by having one fisheye repository for each SAP CI package and one project for each SAP CI package and consequently, the review process is by SAP CI package as well. You can have multiple code reviews for each project.


Crucible project with list of reviews

Code review automated process steps

Below you can find a high level diagram on the steps being done nowadays in an automated way


Code review automated process steps

1. Read package source and 2. Commit to git

This step was already part of the pipeline and is responsible to load the CI package source code when the pipeline runs (currently daily) into our git server.

3. Create Fisheye repository

AFAIK, Fisheye needs a synced copy of your git repository represented as a local repository used by fisheye when doing the searches that is also used for the code review processes. We create a repository per SAP CI package. Only the commits that got synced are visible on your review. We create this local fisheye+crucible repository if it doesn’t exist (via crucible api) also supplying the necessary authorization (we’re using ssh key) to connect to gitea.

4. and 4a. Trigger Git->Fisheye sync

After having a local fisheye repo, we can force an incremental synchronization (delta). This will force Fisheye+Crucible to fetch the latest changes committed to git synchronizing into it’s own local repository. Jenkins pipeline waits until this process is finished


Code review showing changes on the latest commits

5. Create crucible project

As stated above, we create a crucible project per SAP CI package to keep simplicity since our reviews apply to SAP CI package and not to a higher level. If such crucible project doesn’t yet exist we create a new one on the fly. Upon creation, you can configure the owner (we take the identified package responsible and we consider that one as the owner). As the list of reviewers, the whole SAP CI integration team is allowed to review.


Project definition example

6. Create crucible review

We check for existing reviews for the package we’re processing. If they exist in Draft or in Review, we add the latest git changes there. If no open review exist but we have git files that were changed and committed for the package, we open a new code review in Draft mode.


Review details screen example

7. Add committed files to the review

Finally, we add these unreviewed files to either an existing or a newly created review. Then during our daily calls we ask for a colleague to do the review and the reviewer is manually assigned by the owner to the automatically opened review. The review can then take place by the reviewer (he needs to check the code against the code review check list defined) and then he/she can add comments (even on a line level).


Review comments

When it’s time to release the SAP CI package to transport it to the next environments, we manually check that all code reviews for all the packages we want to transport are closed (meaning that there are no unreviewed files).

Value added

We never have unreviewed files that aren’t part of a code review session. Even if you change one file today, and you don’t review it, if you would come back in one year to change another file, the one you didn’t yet review would still be there for you to review. This would mean that we make sure that every change in any file of your cpi package is acknowledged and reviewed by someone at some point in time. All this process is managed in an automated way with no efforts for the developer or the reviewer (they don’t need to know all steps described, only that crucible is maintained up to date with the git source)

Next steps

  • Integrate crucible into the transport pipeline to make sure that there are no code reviews in draft or in review for the packages you want to transport
  • Check a possible integration with JIRA and collect the reviewer from the JIRA User Story (US) automatically as well as showing on JIRA US the reviews associated with


In this topic, I’ve introduced the topic of code review, the challenges we faced and how the whole process evolved over time.

I would also invite you to share some feedback or thoughts on the comments sections. I’m sure there are still improvement or ideas for new rules that would benefit the whole community. You can always get more information about cloud integration on the topic page for the product.


With this post we complete the blog series. You might wonder that this approach deviates a bit from what you’re usually used to see on a CI/CD approach, for instance automatically deploying tested committed code into other environments. In fact, as we don’t want to synchronize from git back to CI (for the reasons I described above), despite technically possible, it doesn’t make much sense to deploy it automatically from git. We prefer to have that control on our side evaluating when the deployments are done to which environments and therefore we trigger the transports and deployments manually after aligning with the functional teams (but by using the Jenkins pipelines specified on the “Release Management” page).

I hope you enjoyed and got inspired to try some of these ideas on your current customer/employer. Please let me know if you need some guidance and I’ll try to help.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Antonio Jorge Vaz
      Antonio Jorge Vaz

      Hi Nuno,
      I waited for the last post to comment, but had to say this - awesome work putting all this together.

      It's very interesting to see that this didn't stop and new functionalites have been added since I left.

      While I think that there's room for improvement on some areas, I also have to say that this brings a good overall understanding on how to leverage the existing tools and bring some governance and quality control (especially for cross-development teams).

      I hope to see a follow up post in few months on the "state of the art" of this landscape.

      Antonio Vaz

      Author's profile photo Nuno Pereira
      Nuno Pereira
      Blog Post Author

      Hi Antonio,

      Thanks for the feedback, grateful for all the work you've done with this and all the contributions you've made to the current solution. I doubt we could have achieved so much in so few time invested into this topic without your help.


      Nuno Pereira

      Author's profile photo Daniel Graversen
      Daniel Graversen

      Hi Nuno

      Thanks for a good series and for bringing awareness that we can deliver better ways to handle our code.

      Review is probably something that we don't do too well as integration developers.

      Compared to our java developer, they have a good process and tools that allows the easily to check what is committed using intellij and bitbucket merge processes.

      There is option for comparing the code and see if it follows your guides.

      I do think the BPMN model is an part of the code that also requires some explanation and where an architect may question some steps that could be performed better in a new context.

      In Figaf give architect the deltas for BPMN and code between releases. I think this gives you a short understanding of what is changed and to see if someone put malicious code into production.

      I think one reason why you we are not doing as much review is that it is individual interfaces that does not make and not something that need to be build and maineded a lot around.