We have a repo that contains a Base code for a React Native App (SaaS)
In the same Repo, We have multiple branches for every client (separated app)
Master contains the main base code (we push any new features/ fixes to it)
Now we have issues when want to push the new features/fixes to other branches! It's about changing the package name and icons etc (native stuff). When open PR to take updates from master => client-1.
So do you recommend any tips that help us to manage all fixes/features in the base code and applying it to other branches without effected by iOS/Android things?
This is potentially an insufficiently specific question but, I'll try to help.
The way I'd approach this is just having develop, staging, and main branches, so I can minimize the conflict potential. In what I assume is a monorepo, I'd then be able to accomplish having base changes get to the client apps in some orchestrated manner, via localized package management by way of leveraging Lerna or Yalc, plus a CI/CD step. In effect, I'd have any changes to base cause an associated version bump of "base" in the dependent clients, and a rebuild + release of those clients.
Related
I am seeking a solution for setting up a git workflow for our team. We are developing native IOS and Android apps. there will be a master project (for each platform) that will contain all the all the core functionality and then a version of the master will be customized for each customer. We need to make bug fixes and changes to common functionality in the master project and these apply to each customized customer build. Changing each customer copy would be unsustainable.
I am currently using a branch for each customer and all common functionality is edited in the a "base branch" but this approach seems messy.
Edit
the main problem i am having with this is when i make changes to the the template project is i was told to "merge" only specific files i would have to checkout the file from one branch to the others (client branches) but this would then over right client specific changes.
Any help would be greatly appreciated.
I have a project.
This project includes 2 apps: iOS and Android.
Apps are similar (doing the same but for different OSes).
The project is considered as completed when and only when both apps are delivered.
Apps then could evolve independently (in versions sense, for ex. there could be 1.3 iOS version versus 1.1 Android one).
I use JIRA for project management.
I wonder how better to organize this project with JIRA.
Option #1:
Create one project and one confluence space for it.
Create one user story per feature and then create sub-tasks inside for both iOS and Android (duplicate subtasks).
Looks messy. And it looks it is hard to recognize which app is in trouble as the whole project is in the same pot.
Option #2:
Create two projects (for iOS and for Android) and one confluence space. Then create stories per project (duplicate stories).
Looks more manageable, but stories duplication looks awful.
Please, help.
Minimize the number of projects, so choose option 1. Use components to differentiate between each kind of subtask. Use another JIRA Agile board (or dashboard) to select just one set of subtasks or the other.
I would recommend using 2 projects, only because the iOS & Android applications may diverge at some point. JIRA allows you to combine all of your projects into a single view with JIRA Agile and JQL.
You can even view them natively on your iOS device using the JIRA Board app: https://itunes.apple.com/us/app/jira-board-kanban-scrum-agile/id934196108?mt=8
I don't think this question belongs here but anyway, it's better to have one application and after you add a task for the iOS team with component iOS e.g., clone that task for Android, and add it under another component, because these tasks might differ in the delivery time, assignees, etc...
I have had this problem for months now, but today I finally found a solution that works us.
When creating a task you can tag it using a label (name it either iOS or Android). I then use the label in quick filters, which allows me to filter on either iOS or Android tasks. Showing only the tasks for one of them.
Board - confirgure - quick filter ENTER labels=iOS
You keep the tasks in one board, and its less messy.
Use the components feature under project.
Project "FACETIND"
Component "IOS"
Component "DROID"
There is a core ERP mobile application for Android. A customer has requested additional features that will require more screens (and Activities) and extra functionality.
Is there a way I can add sort of an extension to the core mobile application in order to intergrate the extra features or should I code on top of the code of the core application?
I am interested in finding a neat solution focused on extendability since different clients might ask for different additional features. How would you deal with such an issue? Any tips on the structure of such a project would also be welcome.
Would it make a difference if the extra features need to use the same db as the core application?
Thank you in advance for your help.
The answer to your question lies in the Open/Closed principle introduced by Bertrand Meyer. Open/Closed Principle is a very simple Object Oriented Design principle which states that
Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification"
From your question its clear that you have identified the core functionalities in your application. So rather than Modifying this core functionalities and making it more specific, I would recommend, on the basis of the Open/Closed principle, that you should freeze your code features and write your customer specific functionalities over it without corrupting the core.
Now to answer your question on what kind of structure you may follow. I would recommend that you create a library project of your core functionalities and make different client specific projects that would include your core functionalities as a library project.
It won't make a difference if your application is using the same db as your core application provided all your applications uses it, else it should not be in your core application in the first place.
Hope this explanation help you.
Update:
My friend pointed out that I may not have understood the question right. So rather than correcting my old post(...which may be useful for others) I am updating it.
So if I understand it right, you have an ERP project which you may not have coded. The right approach, according to me,still would be that you build over this existing code. Rather than making changes on this project, include it as a library because if the project is downloaded from a reliable source, you will have the benefit of getting the updated version as and when it is available.
This is kind of a design philosophy question. Here are a couple choices that might give you ideas:
You could look into making your core application code/features into a custom library. Then your new core application is just a simple wrapper that includes the custom library. Your additional features for a specific customer could then be a different app that also references the core library but will include additional features. There are lots of tutorials on how to turn your app into a custom library. You would end up with different apps that target different a customers. (A tip that took a while for me to uncover is that if you have a resource name in your custom library you can "override" it by using the same name in the app that includes the library. Another tip is that you need to essentially duplicate the manifest of the library in the app by listing all the activities in the library that would be used by the app.) I haven't tried this but it might be that your additional features are each libraries that are included in different apps.
You could have an key the user inputs that will unlock certain features. You could save this as a shared preference so that they don't need to keep entering the key. This approach has the benefit that you can "reuse" features for other clients without any more implementation other than determining which client gets what feature. The majority of users just wouldn't have a key to unlock anything.
Both these solutions should use the same db since they would be calling the same core classes, etc.
Another possible solution is to create a Library Project. Put your core ERP app code inside the library Project, and then create different project for different customers. Each one of these projects will also use the same library project.
Your core library project could expose an api to dynamically register new features (Such as a menu that can expose new menu items).
Currently I am working on an application aimed to small local businesses, which serves as a template for other applications (other stores). The base application allows local stores to send notifications to their customers, depending on the business context, notifications can be to report promotions, inform a client that he can pick up his order at the store, notices of new products in the store, etc ... What I do is work on the template for each client and then customize the appearance of the application in the background but the functionality is the same for everyone. My problem is that every time we have more businesses interested in the application and the problem arises when I find bugs or want further improvements, and to update the code in each of the applications can be hell (open each project, add the lines code, recompile, etc ...), and also publish new applications involves a great job because I have to change namespaces whole project, change the authority of the content provider, update references to the namespace associated with the template, etc. ...
Is there any way that I provide update and / or add portions of code in the original template and the changes are automatically reflected in all projects generated from the template?
I have understood Apache Ant can help with the compiling process of large project with many dependencies, but could be useful in the context of my problem?
The solution that I can think of right now is to create a project library and then put everything common to projects, including resources and Activities. The problem is that for example the application Content Provider could not go there because I need to have a single authority in the Manifiest defined for each application.
In advance thank you very much for taking the time to read my message. Any help or advice is welcome. Thank you again.
My question is there any way that I provide update and / or add portions of code in the original template and the changes are automatically reflected in all projects generated from the template?
Make the core code be an Android library project, and use that library project in all the customer apps.
The solution that I can think of right now is to create a project library and then put everything common to projects, including resources and Activities.
Correct.
The problem is that for example the application Content Provider could not go there because I need to have a single authority in the Manifiest defined for each application.
Your ContentProvider implementation can go in the library project. Your customer-specific project will need the <provider> element in the manifest, with a unique authority, pointing to the ContentProvider class from the library.
I'm developing a series of applications for mobile devices, we'll call them Orange, Cherry, and Pear. Now, because of my familiarity with Blackberry, I chose to begin implementing the first of these three applications, Orange, on the Blackberry platform. I found a way to integrate a number of Blackberry platforms (since they use relatively the same API among different BB operating systems, with some exceptions) into the same codebase. Currently, my codebase looks something like this:
Orange/
trunk/
src/
... orange's source tree...
branches/
1.0/
... orange's source tree as it looked at release 1.0 ...
tags/
1.0.0/
1.1.0/
So, basically, I'm using a version-based methodology to my branching. Now, however, we want to migrate this application to the Android platform (and, at some point in time, probably to other mobile or even desktop platforms). So, my question is, what is the best method for branching with a single application across multiple platforms? I have read Branching Strategies, as well as a number of branching strategy webpages (e.g. http://www.codinghorror.com/blog/2007/10/software-branching-and-parallel-universes.html ), but I'm still unconvinced at branching based on having a 'common' trunk (e.g. as described in the last link as 'Branch per Technology').
The reason I remain unconvinced is that I'm a believer in the version-based branching strategy. It seems logical; if you want to maintain separate stages of development, then branches seem like the ideal way to do this. If I have aspects of the code that are 'common' between all three platforms, then I decide to make an android release, do I branch all of the code from the common and android trunks to make a new release tag? Or, do I keep all of the code in the 'common' branch in the android and blackberry branches as well?
I thought that perhaps another thing I could do would be to create separate projects, for instance orange-blackberry and orange-android. This might clutter my svn repository, however, since we keep all of our projects in the same repository. So, inevitably, I will have orange-blackberry, orange-android, cherry-android, cherry-blackberry, pear-android, pear-blackberry, along with a series of project folders for any other application I create.
So, I'm looking for some feedback about what might be the best way to manage all of this chaos. Also, if you could throw in some ideas about the logistics of transferring from my current implementation to the newer one, (i.e. what svn commands I should use to maintain history), that would be very much appreciated.
BlackBerry Java code is j2me, so source code must be Java 1.3 compliant. Android can use Java features all the way up to Java 6. If you want your app to look decent, you will be using the RIM proprietary UI components (net.rim.device.*) and those won't be available on Android.
I wouldn't consider an Android version of an application to be a branch of BlackBerry. You should just start from scratch. The platforms will share very little code, and the code that can be shared would be best factored into a library jar that both project incorporate.