Poodletooth-iLand/deployment
2015-08-16 02:28:44 -04:00
..
toontown Add submodule and upload the deployment files. 2015-08-13 18:38:01 -04:00
deploy.json Add submodule and upload the deployment files. 2015-08-13 18:38:01 -04:00
public_client.prc Changed the way we call the mongodb so the database match up. 2015-08-16 02:28:44 -04:00
README.txt Add submodule and upload the deployment files. 2015-08-13 18:38:01 -04:00
server.prc Changed the way we call the mongodb so the database match up. 2015-08-16 02:28:44 -04:00
uberdogs.yml Add submodule and upload the deployment files. 2015-08-13 18:38:01 -04:00

This deployment folder contains files that describe how a release of TTSride should be run on the gameservers.

uberdogs.yml contains the 'uberdogs' section of an astrond.yml. Please keep it updated, or else you'll break prod!

deploy.json describes a the environment for a release of TTSride. It contains the version of astron to use as well as the version of Panda3D to use as well as the libpandadna version to use..
deploy.json also contains a version prefix. This is used to generate dev version strings on the development server (which are probably something like ttstride-beta-dev-gabcdef0).
When we deploy a release to prod, we push a git tag named after the version to the repository (i.e. ttstride-alpha-v1.3.7). It is required that the tag's name contain the version prefix specified in deploy.json.
The key 'server-resources' maps to a list of file extensions of files in the resources directory that are necessary to be used server-side. We do not package and deploy art assets onto servers.

Last, server.prc is the configuration file we use for specifying config vars related to gameplay (a variable like want-sbhq should be put in server.prc, while a variable like air-stateserver does not belong here). server.prc is the last portion added to generated configuration files.
We also have a tag system to allow certain blocks of configuration to be used only in a certain environment. This allows us to generate releases that behaive differently depending on the environment that they are deployed in. For example:

-----
want-toontowncentral #t
#<prod>
want-bbhq #f
#</prod>

#<dev>
want-bbhq #t
#</dev>
-----

In prod, the parsed config file would look like this:

-----
want-toontowncentral #t
#<prod>
want-bbhq #f
#</prod>

#<dev>
##UNUSED SECTION
##want-bbhq #t
#</dev>
-----