Versioning of a native Flow app

Using Neos & Flow Installation & Deployment
1

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?

2

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

3

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
4

@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).