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:
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.