Last year i developed a tool for the customers of one of our departements. It was a video based training tool in SAP(blogged about it here). After that other departments were aware of it and wantet to use it for their customers, too.
So then it became a bit more complicatet because we are a data center and therefore have many systems distributed across different system landscapes. So for my the target was to improve the tool and make it more flexible and generic, so that it depends on the respective system landscape and the wishes of the local customers.
It is a Floorplan Manager Application. So the different departments want different themes, different list building and of course different topics and videos 🙂
So I designed my object-oriented-model to fulfill the needs. Nothing very special, but for developing I did not want to go our default way and break the rules. 😉
So to transport all the changes during development from landscape a to b and back to see if everything works on all landscapes like i think and if the tool works on every landscape than it should and then also document everything isn't the best way in my opionion.
So I decided to use abapGit for that. With the use of abapGit also came more benefits during the project and also the potential for the future is really big.
Fortunately, we already had one Git Server in another development department of our company. More precisely they use Phabricator which is a set of tools for software development. One of these tools is Diffusion where you can host GIT-repositories.
So it was a bit tricky to connect the development systems with the phabricator and open all the firewalls. But after a few work and with a bit help it worked.
So this is how the repo looks lke after the tool is productive in the first departments enviroment.
So far I have not used any branches in this project. But this is planned when the developers for the specific department go for the further development. So they could use brances for ther features and fixes and also could develop parallel and independent of the landscape.
It was also nice to try out crazy things during development and if it became to crazy i could go back to the last working stand. (Reset local for the last commit) 🙂
So i think in 2018 everybody knows (and loves? 🙂 ) abapGit, so the following isn't new. This is a part of my project in abapGit of one development system.
So this was the first benefit. I could develop over several systems "at the same time". So in development system A i did something, pushed it to the repository on phabricator and pulled it on development system B and tested the changes. The same worked back just like that. So with rapid speed and no work around it I was able to develop through several development systems. The documentation I had with the commit messages and of course on Phabricator with the history. 🙂
(On Phabricator you have furthermore a project board for your tasks which interacts with Diffusion so that you control the board with your commits. So your work is becoming more transparent.)
When the first steps have been taken, the potential becomes more and more recognizable. Next step is that our partner datacenters which also use the tool get the possibility and know how to get the changes directly from phabricator, means they pull it after every commit. At the moment they are getting all the changes over classical transport requests.
My task would be to build a BRF+ integration for abapGit, because I used it in my first tool and I'm also a big fan of it. 🙂
I hope you get a glimpse of what scenarios are alls optimizable with abapGit. I hope the scenario and the environment have become a bit clear so you understand the background too. 🙂
So then it became a bit more complicatet because we are a data center and therefore have many systems distributed across different system landscapes. So for my the target was to improve the tool and make it more flexible and generic, so that it depends on the respective system landscape and the wishes of the local customers.
It is a Floorplan Manager Application. So the different departments want different themes, different list building and of course different topics and videos 🙂
So I designed my object-oriented-model to fulfill the needs. Nothing very special, but for developing I did not want to go our default way and break the rules. 😉
So to transport all the changes during development from landscape a to b and back to see if everything works on all landscapes like i think and if the tool works on every landscape than it should and then also document everything isn't the best way in my opionion.
So I decided to use abapGit for that. With the use of abapGit also came more benefits during the project and also the potential for the future is really big.
Phabricator
Fortunately, we already had one Git Server in another development department of our company. More precisely they use Phabricator which is a set of tools for software development. One of these tools is Diffusion where you can host GIT-repositories.
So it was a bit tricky to connect the development systems with the phabricator and open all the firewalls. But after a few work and with a bit help it worked.
So this is how the repo looks lke after the tool is productive in the first departments enviroment.
So far I have not used any branches in this project. But this is planned when the developers for the specific department go for the further development. So they could use brances for ther features and fixes and also could develop parallel and independent of the landscape.
It was also nice to try out crazy things during development and if it became to crazy i could go back to the last working stand. (Reset local for the last commit) 🙂
abapGit
So i think in 2018 everybody knows (and loves? 🙂 ) abapGit, so the following isn't new. This is a part of my project in abapGit of one development system.
So this was the first benefit. I could develop over several systems "at the same time". So in development system A i did something, pushed it to the repository on phabricator and pulled it on development system B and tested the changes. The same worked back just like that. So with rapid speed and no work around it I was able to develop through several development systems. The documentation I had with the commit messages and of course on Phabricator with the history. 🙂
(On Phabricator you have furthermore a project board for your tasks which interacts with Diffusion so that you control the board with your commits. So your work is becoming more transparent.)
Outlook and counclusion
When the first steps have been taken, the potential becomes more and more recognizable. Next step is that our partner datacenters which also use the tool get the possibility and know how to get the changes directly from phabricator, means they pull it after every commit. At the moment they are getting all the changes over classical transport requests.
My task would be to build a BRF+ integration for abapGit, because I used it in my first tool and I'm also a big fan of it. 🙂
I hope you get a glimpse of what scenarios are alls optimizable with abapGit. I hope the scenario and the environment have become a bit clear so you understand the background too. 🙂
- SAP Managed Tags:
