The scope here is the server set up or rather environment used for specific purposes, so we should maybe go with environments like this:
Production Environment (a.k.a Public) - This is the public release and is never touched except for official releases or bug-fixes
Staging Environment - this is an (ideally) always working incarnation of the upcoming release (not necessarily the most recent development state), mainly used for final testing and demonstrations. It should not be used for any development work.
Server-Dev Environment - this is intended for doing any sorts of server-side development and is therefore to be regarded highly unstable and no one should expect it to work reliably.
Client-Dev-Environment - this is meant to be a environment for client side development. This means that while it should run (some) development version of the server code, it should be kept as stable as possible. The idea here is to have a server environment that has the cutting-edge features that vapor developers can use and rely on to some extent. Breaking this environment might block vapor developers, so it should be updated carefully.
Of course in the end these environments end up to be mapped to branches or tags. For this I would vote to have production on master and create new staging, server-dev, client-dev branches (maybe renaming the current development branch to client-dev or server-dev).
Each environment needs to have its own database copy and configured webspace. Is there anything against having everything but production on the same IP with either virtual hosting or using different ports?
Also we need a scheme to eventually sync the databases back and forth (maybe just back) and maybe some sort of migration for DB schema changes, to be able to roll back.
Pierre henri Seylan on October 20, 2014:
What is the best way to integrate the mobile development in this scheme? Points to consider are:
Merging of the iPhone API with the existing Vapor API
Need for separated testing environment between the mobile app and vapor studio
2-Shell on October 20, 2014:
I consider the iOS app to be a sibling of Vapor. As such I don't see the need for a separate testing environment. I think it should just use the same as Vapor.
The merging of the API should be done really soon anyway. It would be good to have an overview of the differences of the two APIs (in their current state).
I think once we've set up the proposed four environments, we're on our way and if over time it proves necessary to have another one, it should be easy to add a mobile-testing environment. But for now I think the four should just suffice.
Comments
Pierre henri Seylan on October 20, 2014:
The scope here is the server set up or rather environment used for specific purposes, so we should maybe go with environments like this:
Of course in the end these environments end up to be mapped to branches or tags. For this I would vote to have production on master and create new staging, server-dev, client-dev branches (maybe renaming the current development branch to client-dev or server-dev).
Each environment needs to have its own database copy and configured webspace.
Is there anything against having everything but production on the same IP with either virtual hosting or using different ports?
Also we need a scheme to eventually sync the databases back and forth (maybe just back) and maybe some sort of migration for DB schema changes, to be able to roll back.
Pierre henri Seylan on October 20, 2014:
Points to consider are:
2-Shell on October 20, 2014:
As such I don't see the need for a separate testing environment. I think it should just use the same as Vapor.
The merging of the API should be done really soon anyway. It would be good to have an overview of the differences of the two APIs (in their current state).
I think once we've set up the proposed four environments, we're on our way and if over time it proves necessary to have another one, it should be easy to add a mobile-testing environment. But for now I think the four should just suffice.