具有CI工作流程和单一功能部署的庞大TYPO3项目

Question

We've a huge TYPO3 project with several developers. We trying to setup a CI infrastructure, with GIT, composer and Jenkins. We have development (vagrant), staging and production environments. It is quite common that multiple features are on the staging server at the same time. Because different people are in charge to test these features, the features are usually not applied to production server at the same time. So we set up the following workflow:

All developers start from the master branch and creates it's own feature branch. When the feature should go to staging server, the feature branch should be pushed. We have a configuration where all feature branches are defined, which should go to staging. Mr. Jenkins merges all feature branches before building the project and deploys everything to staging server. When one feature is successfully tested and should go to production, the feature branch must be merged to master. Mr. Jenkins builds the project and everything will be deployed to production.

So far we are very satisfied with the workflow except of one point: composer.lock file.

A feature could update or install a package. As soon as two feature branches manipulate the composer.lock file, there is a conflict with the "hash" of the file which cannot be automatically be merged.

In my opinion there is no clean solution. The only solution for me is to exclude composer.lock file from repository and let Mr. Jenkins do a "composer update" which leads to undefined state of all required packages. The cleanest way in my opinion would be to merge the whole development environment to production after all features have been tested, but this cannot be made because of organizational reasons.

Is this workflow a huge edge case, or is there a best practice solution?

Thanks for any help!

Answer 1

You really should add the composer.lock file to you git project, because otherwise you will get different versions at jenkins and of course for every developer!

I wouldn't merge more than the current feature + master on jenkins and would solve possible merge problems manually

Answer 2

My suggestions are:

• keep the composer.lock on (feature) branches and (version) tags only
• branches are stable and the version context for developing a new feature is locked
• remove composer.lock from the main development branch (master)
• master is always bleeding edge and development occurs until feature (or feature set) freeze
• when merging a feature branch to the development branch you exclude the composer.lock file
  • you could use git merge --no-commit and then edit the merge, unstage composer.lock, then git commit -m "merged <feature-branch>"
• on feature freeze, branch out (new version tag) and add composer.lock to lock the version context

Boils down to: feature branch (locked) ⇾ dev-master (unlocked) ⇾ version tag (locked) .

---

• build deployment package from (locked) version tag + distribute (release)
• install/upgrade a release package on production OR follow the approach of using composer on production box and install the version tag :(

The cleanest way in my opinion would be to merge the whole development environment to production after all features have been tested...

Merging to production :) - err, no, that would be too easy!