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.
Related
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.
How are engineers utilizing kotlin multiplatform between iOS + Android?
We are adding a build-phase inside of the iOS project to compile the iOS build, do people have this pre-compiled for the main product app / separate from the repo?
I think this varies a lot across teams, generally speaking I'd approach it like this:
If you want gradual experimentation and in a more isolated way, a repository for shared code with dedicated team, that provides a binary (now XCFramework is possible with Kotlin/Native) can be a good option. The iOS team just pulls that in as an external lib.
The problem with the above is exactly isolation (harder to debug and read this shared code), if your goal is to overcome working in silos and include the iOS team more in the discussion I think cloning this shared code repo and using https://github.com/touchlab/xcode-kotlin to read & debug it is a nice lightweight approach to have this part of your code more open to iOS devs
If you want full contribution - iteration of read/write from iOS I'd go with a mono repo, full setup of the KMP ecosystem
Hopefully this covers your question at least in some perspective, let me know if you are interested in other aspects
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"
Imagine mobile application that is planned to be implemented for both iOS and Android.
Development was started from the iOS version only and now the time has come to start with Android one.
iOS application's code is stored at its' own Git repository that named after the apps name, e.g. "MYApp".
Now I would like to create one common repository for both iOS and Android applications and name it again after application's name: "MYApp".
It is not a problem at first glance.
Just create repository, create 2 subfolders there and start working.
But.
I would like that Android developer could work only with his folder and iOS developer only with his one too and both of them could see only their own folders related history (log).
I worked with SVN previously.
Usually I created subfolders and you could checkout any of them to work only with this subfolder.
History was also filtered to your scope.
I'm stuck with implementing the same under Git.
Please, help me to find right direction.
I will sum up solutions suggested.
Use branching for different platforms. I don't think that it is good idea, because branches used for another purpose. It seems to me very "jacky".
Use submodules. Just create as many repos as platforms you are targeting to, name them "MYApp-iOS", "MyApp-Android", etc. and finally end up with "master" repo, that could be names as "MYApp" (without any suffixes). Then add all related repos to "master" one with git submodules feature.
Use git slave. Investigating...
Please, feel free to edit this list to brainstorm the problem.
There is a way to keep to kind-of-related separate projects in a same git repository utilising git branching.
But keep in mind that that is not why branching was implemented into git. One of its uses would be development of a radical new functionality to your app that might not see the release any time soon for example.
On the end: it is a matter of opinion. If you are prepared to administrate a more complex repository just to keep both codes on the same place - you can.
I would definetly make two separate repositories though. Couple of opinions on this topic can also be found here on SO: Git branches with completely different content
EDIT:
gitslave seems to tackle your problem. You might want to give it a try.
i have to setup an android maven build for a customer, which previously was based on ant.
The base app is a white label implementation and the app is distributed to several third party customers. Each of those customer versions uses the same source code and a set of shared resources. But every customer also has some resources specific to their company (constants, assets, etc).
The structure of my android project looks like this. I only included relevant files/folders and the structure is remained from the ant build:
App
|--src
|--res
|--res-customer1
|--res-customer2
|--pom.xml
This means i have to build multiple .apk artifacts from the same source with different resources. What is the best approach to do this?
The first thing i tried was to use different profiles in my main projects pom for every customer. Then i wrote a shell script to execute all maven builds (1 per customer).
Then i came up with using only one release profile in my main project and passing the customer specific properties via command line. Properties are passed via a shell script, similar to my first approach.
But i'm not happy with that, so i thought about using multiple modules. One per customer. But my problem here is, how i can build those from the same source without copying the source from my main project over to all modules?
Or do i have to setup an android project for every customer and refer to my main project as apklib? Will this merge the shared and the customer specific resources?
Is there a best practice to do something like this?
Any other approach is also very welcome.
For only small differences it can be sufficient to just use profiles and a few different properties with resource filter. Profiles however are a bit of a bad pattern in the Maven world and can be hard to work with.
Your hunch to use separate modules for each customer and have the base application be an apklib is correct. I know of several people that have reported on the maven android developers list that this is what they use and works for them. I would personally use that approach in your case as well.
In general I would suggest to ask or at least mention this question on the mailing list.