I know it's a broad question so I'll try to be as specific as possible.
This question is more an "organisational" question than a technical one.
We have a multi-sided project with these main components:
- A server, hosting the core business logic (data models)
- A backoffice for clients which uses the core business logic
- An application API (REST) which uses the core business logic too
- There are smartphone apps (iOS and android) using the application API
- There are another tablet app (android) different from the smartphone one using the same application API.
Soon, I'll be in production with active clients. And as any project, I'll need to maintain all different components over time. That means all of the following can be upgraded:
- the code of core business logic in the server (used by the back-office, the API, and as a side effect, by mobile apps)
- the API itself (used by both smartphone and tablet apps)
- all the mobile apps (via appstore/googleplay)
Of course, server-side parts (core business logic code and API code) can be changed immediately by myself. However, new mobile apps must be downloaded by the clients on the appstore/googleplay, and I can't be sure they're up to date.
Could you provide any guidance, good practices tips, to make theses upgrades smooth and, unrisked for the client?
Which component do I need to "version"? How to ensure everything works even if the client does not upgrade its mobile app? Should I force him to upgrade to make my work easier?
In a word, how should I organize to make my multi-sided-project live over time?
Best Answer
As you can't control when the mobile apps will be updated to a new release, you need to version at least your REST API. If you don't it will be impossible to make backwards-incompatible changes to that interface.
Besides the REST API, it is a good idea to version also the other communication interfaces that go over a network interface. That way, you are also not forced to upgrade all backoffice clients at the same time as the servers and you can implement a gradual migration to a new version with a "beta test" period.
Besides versioning the communication interfaces, you should also try to make the changes backwards compatible as much as possible. Ideally you might roll out a new interface version that still fully supports the old clients so that they don't notice anything has changed.