The Blessing and the Curse of SAP MDK
Working in SAP Mobile Development Kit (MDK) presents unique challenges, especially when collaborating with a team of developers. While MDK takes care of a lot of the heavy lifting in mobile app development, making custom tweaks can be tricky because of the way the framework is set up. It gets even more complicated when multiple developers are working together, often leading to headaches with version control and syncing deployments.
Git Control and Mobile Services Destinations Issues
One of the biggest challenges in team-based SAP MDK projects is managing changes through Git and getting them deployed to SAP Mobile Services. To see any updates in your MDK application, you have to deploy the new code to Mobile Services, which means the latest deployment will replace whatever’s already there. Consequently, if multiple developers are working on the same codebase, their changes can conflict, leading to a frustrating cycle of overwriting each other’s work.
Example Scenario
Let’s explain this issue a bit further. We have an MDK application set up in a Git repository and connected to Mobile Services. We have two developers working on this application, we’ll call them Bert and Ernie. Bert and Ernie both clone the repository and start working on feature branches in a new application they’ve set up in SAP Business Application Studio (BAS).
Bert makes some changes to the front-end and would like to view those changes. In order to do that he must deploy the application to Mobile Services, which he does and can now see his changes on his local machine.
However, Ernie, who is working on the same part of the application, would also like to see the changes that he has made. So he also deploys his changes to Mobile Services. Bert’s original changes are now overwritten because even though the codebase that each developer is working from is unique to their local machine, in order to view the changes the code must be deployed globally in Mobile Services.
Both developers can still see their changes in the code in their respective feature branches on Git, but they cannot view their updates in the app without redeploying to Mobile Services, which restarts the cycle of overwriting.
Our Solution
Through working in the MDK, we’ve found the best solution to this process consists of four steps:
1) Create a Main Branch for Stable Code:
This is similar to the standard approach for using Git. The main branch will be only used for deploying to production (or a final testing environment). When a developer is working on a feature, they create a feature branch and work from within that branch.
2) Unique Mobile Services Applications:
Here’s where things get a little different. We will set up unique individual Mobile Services applications for each developer and this is where they will deploy any changes in their code. Each developer creates their own SAP BAS project, creates their own branch in Git to work from, and connects it to their unique Mobile Services application. For example, say there are five developers working on a project, then there will be six Mobile Services applications created (one for each developer and one for the main branch). In the code on their feature branch, they MUST update the service and JSON files to be pointing at their specific Mobile services application. This happens each time a developer creates a new feature branch.
3) Deployment and Merging:
Developers deploy their changes to their unique Mobile Services applications to view updates without affecting others. Once changes are reviewed and approved, they merge the changes from their feature branches into the main branch in Git. A senior developer oversees the main branch and does a separate deployment to the main Mobile Services application when ready.
4) Continuous Integration:
Our developers can now pull from the main branch to stay up-to-date with features from other team members. This approach ensures that individual changes do not overwrite each other and provides a clear path for integrating and testing new features.
Example Scenario with the New Process
Let’s revisit Bert and Ernie, but this time using our new process. Bert and Ernie both start by creating feature branches for their work. Bert makes his changes and deploys them to his unique Mobile Services application. He can now see his changes without worrying about affecting Ernie’s work.
Ernie, meanwhile, is also making his changes and deploys them to his unique Mobile Services instance. Both developers can work independently, see their own changes, and make adjustments without any risk of overwriting each other’s work. Since their mobile device or emulator is showing them their specific Mobile Service application, there’s no danger of overwriting each other’s work during deployment.
When Bert is ready, he pushes his changes to his feature branch and creates a pull request. Ernie does the same when he’s ready. A senior developer reviews both pull requests, merges them into the main branch, and then deploys the stable version to the main Mobile Services application. This process allows Bert and Ernie to focus on their development tasks without worrying about constant redeployment conflicts.
This new process might take a little more time to set up initially but significantly improves developer satisfaction. Developers can work without fear of losing or overwriting progress and can collaborate more easily by pulling changes from the main development branch when needed. This leads to a far more efficient and streamlined workflow compared to the previous setup.
Conclusion
When working in the SAP MDK, a structured branching strategy and individual Mobile Services applications help teams avoid overwriting each other’s work, making collaboration smoother and development more efficient. Our Git repository and main Mobile Services app now act as the ‘single source of truth,’ keeping everything consistent and allowing the team to confidently build, test, and deploy without conflicts.
