Versioning of a native Flow app

Hi there,

I am just starting the development of a native Flow app and am wondering if there is a best practice to put it under version control e.g. Git.

This is my approach:

I installed Flow via Composer (without “–keep-vcs”):
composer create-project typo3/flow-base-distribution myproject

After that I got the composer files and a .gitignore file with the following content (so that the rest of the project is totally unknown by Git at all):
/Build/
/Configuration/
/Data/
/Packages/
/Web/
/bin/
/Readme.txt
/Upgrading.txt
/flow
/flow.bat

I changed parts of it to the following:

/Data/
/Packages/Application/Flowpack.Behat/
/Packages/Framework/
/Packages/Libraries/
/Web/

so that I can put all the rest ( /Package/Application/ ) under my own version control.

Database configuration etc. that must not be put under version control will then be put into global Configuration/ and every package-specific configuration will then be put into /Packages/Application/Acme.Project/Configuration/ and will go into Git.

Would you do it in the same way?
Do you have suggestions/recommendations to improve this approach?

Hi

You can create your own base package with the Configuration Folder and a composer.json.
Inside the composer.json you require the typo3\flow package, your own packages and any additional Packages.
With this step you have your Basic setup versioned.

On a clean install you now just have to checkout your basic git repo and run composer install to get all your code.

For a more advanced Installation you should have a look into the typo3\surf package. There you can completly automate a deployment to multiple servers incl. database upgrades rollback ect.

Regards
Beat

Generally sounds fine. What you should also version is the composer.json and composer.lock files because they define the versions of packages that get installed. Good for update management.

1 Like

@christianm: You’re absolutely right.
That’s why they aren’t mentioned in the .gitignore file.

@sintbert: I think your solution is more relevant for reusable packages/extensions that should be provided to the community (e.g. to be used by NEOS or other apps).