[Flow] putting a FLOW project under version control with git

[Andreas Wolf]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

it's been a while since the question was raised, but probably this
answer is still helpful for some people...

Am 21.11.2013 15:01, schrieb Lorenz Bausch:
> The command mentioned in the Definitive Guide "composer
> create-project --dev --keep-vcs typo3/flow-base-distribution 
> tutorial 2.0.0" also creates a .gitignore in the root folder with
> the following content:
> 
> ---------------------%<--------------------- /Build/ 
> /Configuration/ /Data/ /Packages/ /Web/ /bin/ /Readme.txt 
> /Upgrading.txt /flow /flow.bat 
> --------------------->%---------------------
> 
> This prevents any configuration files or packages from being
> checked in and I wonder if there's any best practice or standard
> approach to use git, besides just deleting the .gitignore.

I use the following approach:

No project uses the Production/Development contexts directly, instead
a subcontext based on the name of the machine or the deployment type
("QA", "Live").
The machine-independent configuration for each context (Dev,
Production and Testing) is put into Configuration/<Context>/, while
machine-specific config (DB, mailserver auth etc.) is in
Configuration/<Context>/<Machine>/.

Currently, the configuration is deployed by TYPO3 Surf and therefore
the config we use on the machines resides in Surf's distribution
folder (Build/Surf/). The context's main configuration file is the
same for all deployments, while the specific deployments (QA,
production) have their specific configuration files.
The Surf configuration currently is the only part we version, which
has the downside of every developer being forced to regularly copy the
configuration files from there to their Configuration/ folder.

Surf also offers a way to encrypt the data, making it safe to put e.g.
database passwords in there.


One can argue if Configuration/ has to be version-controlled in that
scenario. I would version the main context config files
(Configuration/Development/Settings.yaml etc.), because that way
everybody has the same configuration on their machines when
developing. For the production releases, the config deployed by Surf
might be enough - also Surf wants to completely control the
Configuration folder IIRC.


TL;DR: I think the global parts of Configuration/ should be under
version control, while machine-specific configuration should be
deployed by Surf or $deploymentTool.

Perhaps others will also share their configuration? I'd be interested
in seeing other approaches to that problem.


Cheers
Andreas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iF4EAREIAAYFAlLIAjMACgkQVRefK2MMWg6ZDwEA3lAKJ2lVBDWJzEcUfzgn5Pbp
QtssD4cGxzdDOe1qAk0BAKPcBNbImTG9e9ITtLJwPpUhdqY93rBe+HLKJgeC15El
=ah26
-----END PGP SIGNATURE-----