It's time to improve my workflow. I never had the responsibility of setting up the infrastructure, managing git, versions or releases. For me it was simple push/pull most of the time and I think, the workflow wasn't state of the art. I'd like to change it and as there are so many ways, I'd like you to help me, finding a good one.

I read about good solutions here and there (e.g. Docker), but I'm a bit lost due to the variety. I'm interested in something stable, smart, simple.

I'm handling the versioning (git tags) manually; Example: Version 1.2.3 (1 = major release [huge changes], 2 = minor release [features], 3 = patch level [bug fixes]). I'm not using build numbers. Should I, why? I can't see the advantage as long as working alone or in a small team on private code.


  • Development (dev): local
  • Testing (test): online
  • Production (prod): online

When I've a new version or testable commit, I install it on the test environment; as soon as it's declared as stable, I do the same for prod.

I use bower (dependencies) and grunt (tasks) for the frontend-development, but run it only in the dev-environment.

Workflow for a normal project:

  1. init external git repository
  2. clone empty git repository locally
  3. Install packages (Symfony, etc.) via Composer
  4. Configure packages (config.yml)
  5. Create local parameters.yml
  6. Development (dev)
  7. Cloning (test/prod)
  8. Create parameters.yml for test/prod
  9. composer install / composer update
  10. Possibly running some scripts php bin/console ...

Problem: I configure (4) the installed packages (3) locally, but I don't push the vendor-directory. When installing the packages (8, composer.json), I'll get errors, because the config.yml has configurations for yet not-installed packages.

My current solution is to upload the vendor-directory manually for the first installation, to avoid this conflict. I don't like the solution. How to improve my workflow?

  • 2
    You seem to know about this, but I'm adding it nonetheless: semver.org Oct 5, 2016 at 14:29

1 Answer 1


For the config.yml, an environment variable would be a more modern setup:

# app/config/config.yml
    vendor: '%env(VENDOR)%'

Having a second yaml file with a default directory would avoid the error:

# config/default.yaml
    env(VENDOR): '/mnt'


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.