Deploying UI5: Mapping the solution and scenarios
In the first blog of this series I just got you interested, dangled out the technology choises and why this whole approach is good.
Now lets look at the different deployment scenarios depending on your setup.
HCP – All in the cloud
In this scenario you are devloping and deploying in the HCP cloud. This is probably the best as it is a simple ‘Deploy’ button. Ideal. I am not sure though that you get any minification or creation of dbg sources or any of the other goodies I talked about in my first blog. This is more than likely on the roadmap but I am not sure if this is there yet. Perhaps you can enlighten me I will certainly update it.
This scenario looks like this:
All in the cloud.
Local development with Git
This scenario is one that I have used on several clients and I know that others use it too. Source code is developed locally and commited to github or similar in the cloud. Testing is done on local servers with tunnels to odata sources. I mentioned that Graham Robinson’s deployer was an inspiration to this series and this is pretty much what is happening in this scenario.
It looks like this:
All in the firewall
The scenario we are going to focus on mostly in this series is this one. All in the firewall on ‘On premise’ as you cloudy types like to say.
source control, developement workstations and the odata sources all are in the firewall and there will be no naughty touching any fluffy cloudy services thank you very much.
As expected it looks like this:
Local Deployment
So with local development you have a little bit more of the control of having the basis people open up ports and trust the source control server and do something very similar to what Graham achieved with his Git and Local development. But basis people being basis people instead of going for a deploy on push to source control (ideal) I am going for a push to Gateway. I can contol this a little more because I am going to carefully refactor (hack) a local copy of the /UI5/UI5_REPOSITORY_LOAD_HTTP function module to accept a zip file that I will prepare with grunt.
You should note that we have all our projects / apps under one big folder. Normally I am an advocate of one rep per app but in this scenario we didn’t have that control over the source control and it made things simpler for our cross-app navigation. As bonus I found a grunt package that enabled me to create one grunt file and then have one project.json file that pointed to that grunt file to avoid repeating all the build steps for each project aka app.
The simple folder layout looks like this:
Right, so now we are done with all the introductiony stuff. Next time we will get our grunt on.
<– Previous blog: Introduction Next blog : Getting our Grunt on –>
Those are actual napkins, right?
Yes they are! Thanks for noticing!
The napkins are yet another idea taken from me without providing recognition. 😉
See http://scn.sap.com/community/developer-center/hana/blog/2015/10/25/sap-endorses-nodejs
I demand payment of red wine - a simple apology will not do. 😆
Yet another?
Well...I was thinking of exactly that blog so I guess I will find a bottle of chateau de chasselas the next time I am up at the beach office.
The Mentor Beach House is ready for your first visit.
Hi Nigel,
How do you actually tell your customers running "On-Premise" (ABAP GW) that they need a Git because ABAP BSP Repository does not provide source control?
This is actually the most painful part IMO - trying to make them understand what SAP does provide and what SAP does not provide.
Do you have some support documentation you use or I could use where somehow SAP states the value of Git vs ABAP Repository? (as long as there's the SAP logo on the document they don't really care)
Cheers,
Dan.
This is an ongoing issue Daniel We do have source control - SVN - inside the firewall. And we are trying to get git but this is like trying to turn the Titanic.
Sorry I dont have a magic document but ABAP is a snapshot repo (an that's being generous) with no capability for branching which is critical anytime you need to maintain hotfixes in prod and new dev features.
I do know that hana server sp11 is out and has git built in ... so convince them to upgrade to that.
HTH,
Nigel
Hi Nigel,
I agree, it's been an issue since SAP decided to use Gateway to deploy and run UI5 - at the very start we would really do all of this in AS Java and NWDI even thou it sucks does provide the minimum for source control.
As far I understand, it's irresponsible from SAP to promote "use ABAP to run your code" but not provide simple "guidelines" for source control of the artifacts that are generated - most SAP Customers do expect "SAP has it all covered" - they simply don't in this case and it's very much up to the Customer running "On-Premise" to deal with source control system.
When you refer to the docs, it's only mentioned the "UI5 Repository" (BSP Repository) - so trying to talk a Customer into understanding SAP does not have it covered, the Customer itself does not have a decent source control system in place is simply madness.
Quite nice, you run version A or B you don't have such issues since SAP does provide source control.. but really, there are so many easy options around that this should be easy to cross out.. Gitlab & Docker and in 4 hours you have it all.. but since there is no direction from SAP, it's a "developers word" vs "we know what" and usually these things are either neglected or not very well understood by stakeholders since it's not "official words".
Thanks for your input, I'm just another developer doing battles to have simple tools that are so well-known everywhere but they somehow never make their way into SAP Landscape.
Cheers,
Dan.
PS: IMO a simple dropbox account does a better job than ABAP Repo.. - at least I can rollback code with ease when needed.
😉
Hi Nigel,
what's up with next blog 'Getting our Grunt on'. Link is dead.
Cheers,
Steffen
Thanks for noticing Steffen
I have fixed it now.