Q&A on moving from Eclipse to UI5 tooling

[rsletta]

Update 08.04.2020: peter.muessig has releases two great blog posts on thë topic of UI5 tooling. Q/A for "UI5 Tooling SAP Community call (April 1st 2020) "and "UI5 Tooling: a modern development experience for UI5!". Please check them out. (But read this one first, of course. ?)

On April 1 2020, SAP arranged a webinar on the UI5 tooling, with peter.muessig. After the event, I received some good questions on Twitter, on transitioning from Eclipse to UI5 tooling. While I don't consider myself an expert on the subject, since I've not done much UI5 development in Eclipse, I'll do my best to answer the questions. In the spirit of Scott Hanselman, I'll answer in the form of a blog post, so others also might benefit from it.

Background

There are several ways to go about, developing UI5 applications. For many years, the two officially supported solutions from SAP has been Eclipse, with SAPUI5 Tools for Eclipse, and SAP Web IDE. There has also been very good community support for JetBrains WebStorm.

In 2018, SAP announced the new UI5 tooling, based on what has become the defacto standard platform for web development, Node.js. Together with a growing community, this has given developers much more flexibility when it comes to developer environments. The UI5 tooling has been implemented in SAP Web IDE, and with the end of support for SAPUI5 Tools for Eclipse from SAPUI5 v1.71+, all options are now centered around a common core toolchain. And with that, development best practices are universal across all platforms.

The options going forwards

• SAP Web IDE - Running on SAP Cloud Platform NEO, this is a mature cloud based IDE. This is a very safe choice, if you haven't built the skillset to run a local Node.js based environment.


• SAP Business Application Studio - The new cloud based IDE from SAP, running on SAP Cloud Platform Cloud Foundry. It's very good, if I may say so.


• Bring You Own Editor - Use your editor of choice, together with the UI5 tooling, giving maximum flexibility. Some popular alternatives are Microsoft Visual Studio Code and JetBrains WebStorm. By the way; SAP is actually developing several extensions for Visual Studio Code, for example for developing with the SAP Cloud Application Programming Model. But that's another topic.

The Q&A

While I have rambled on about the background in a broader sense, the questions at hand are directly related to the third option. And while I'll now try to answer them as best I can, I would like to recommend a great blog post series by uxkjaer, on "End-To-End setup of local development environment with UI5 Tooling".

While starting a fresh development, what [my organization] do, is we create a new UI5 project in eclipse, deploy it on the server and then start with the coding. I am afraid whether its the recommended practice, but this is [how] people in my organization are working. So below are few of my queries for which I am unable to find the answers :

Q1: How do we control the versioning of projects using tooling in a multi developer environment? Like in eclipse we have the functionality where in it notifies a conflict if someone else is doing the changes in the same application.

A1: Version control with Git is considered best practice for all UI5 development, regardless of the tooling. While this is a topic in itself, the recommended way is to keep the source code in a central repository, either on a selfhosted solution, or using a service like Github, Gitlab, Azure DevOps, or Bitbucket. Using a service is highly recommended, as they offer additional functionality connected to version control. Keep that central repository as the source code truth, and have all developer work towards it.

There is a learning curve attached to working with Git. But today, git is considered a core skills for developers, so this is time well spent learning. openSAP offers a fantastic course on the subject, called SAP Cloud Platform Version Control with Git. Don't worry about the title, it's not SAP Cloud Platform specific, and git is a univeral tool. The course will teach you everything you need, to effectively use it.

Q2: How to do we create transport requests using tooling?

A2: There is no built in solution for creating transport requests, as that is platform specific, and considered out of scope for the UI5 tooling. But there are several options for deploying to a SAP Netweaver system. I have experience with a Node.js tool called grunt-nwabap-ui5uploader, which now is part of the ui5-nwabap-deployer tool, that deploy using the ADT functionality. This includes that ability to create a transport, or use a predefined one.

Another solution, brought to my attention by nabheetscn is the SAPUI5-Deployer, which might suit some better, as it is ABAP based, and running on the SAP Netweaver system.

Update 06.04.2020: As kkronawetter add in the comments, SAP Web IDE supports transport creation. This is a feature of SAP Web IDE, and not a part of the UI5 tooling.

Q3: What is the best practice one needs to follow during development? I mean is it that first we do the entire development and then finally we deploy the project on server?

A3: This is also a topic that could cover a whole blog post series, and also something with lots of different opinions. But I can give you a short recap of the steps I consider best practice of a project startup.

1. 
   

   One person on the team creates the scaffolding for the project. Either using a template in SAP Web IDE, using Yeoman generators, or some other sort. This is a bare bones application. It's good practice that this scaffolding will run without crashing, to have a working starting point.

   
   


2. 
   

   Initialize the project as a git project, to start tracking changes.

   
   


3. 
   

   Push the project to a central repository.

   
   


4. 
   

   Other developers clone the project from the central repository, and start working.

   
   


5. 
   

   Developers implements functionality, and (git)commits according to internal standards. I would recommend commiting often and incremental(small changes), and push to origin (central repository) at least daily.

   
   

   Use git branching. A blog post I found very usefull on my git journey, is "A successful Git branching model" by Vincent Driessen. As a minimum(in a on-premise scenario), I would at least implement a master branch(the branch releases are deployed from), a development branch, and use feature branches locally.

   
   

   Use git stash to prevent committing and pushing knowingly broken code.

   
   

We only deploy releases to the runtime platform. A release is a functioning version, that has some new functionality since the last release. We use tagging system i Git, to identify releases. Releases are deployed from the central repository, either using CI/CD tooling, or manually. First release is when we have something of value to show the client.

With the metadata of the OData service available, it is possible to develop using a mock service, enabling frontend developers to develop disconnected from the backend. And even before the backend is ready, if that's the case. vobu has a great blog post on that subject, as a part of his series on testing UI5 app.

Q4: What is the advantage of doing development using tooling?

A4: We have to differ between developing using tooling, and developing on a local environment. Going forwards, all UI5 development will be using the UI5 tooling, disregarding if using SAP Web IDE, SAP Business Application Studio, or using your own toolchain. My take on this, is that investment in the skillset needed to use the UI5 tooling effectively is invaluable. It gives a solid foundation going forwards, using using universal web development best practices.

It is very smart to start early, when there are many new topics being brought to the table. I would recommend starting with implementing git in your current workflow, so you don't get to many new things at the same time.

The next thing I would look at, is getting familiar with the Node.js environment. Here I would recommend following along with dj.adams.sap YouTube series #HandsOnSAPDev. The first couple of episodes are good starters on Node.js. There are also tons of other resources out there on this subject.

You organisation can consider transitioning to SAP Web IDE or SAP Business Application Studio. While they are paid services, they also opens up a lot of beneficial options, including easy access to on-premise systems through the SAP Cloud Connector. Both services are available from your SAP Cloud Platform trial accounts, to try out.

Now for the question on local vs cloud based development, I would say that there are several benefits. The biggest is probably flexibility and speed. In addition to be able to develop while completely offline, it also lets developers choose their own tooling, like a prefered editor. With the attention Visual Studio Code has gotten from SAP lately, and the similarities with SAP Business Application Studio, it can be a solid choice going forwards.

In closing

I hope I have brought something to the table with this blog post. If there are any more questions, or someone has something else to add, please do so in the comments below.