0

We are using Atlassian Bamboo to deploy our web applications to testing and production servers. This is a two-step process.

  • build and test the release
  • deploy the release to the environment

This run relatively stable, but we are running into some issues with Symfony 2 projects.

Step 1 simply checks out the most recent version from the app from Git, does some tests and other tasks, including composer:install. This last one will execute some scripts (post-install): buildBootstrap, clearCache, installAssets, installRequirementsFile and removeSymfonyStandardFiles.

This step is executed on the build server. Since the parameters.yml file is not present in Git, composer install fails. If we do a composer install --no-scripts, the build succeeds as these scripts are never called.

Step 2 is to ship the files to the production server, install the parameters.yml (which is copied from a predefined location on the target server), do a app/console cache:clear and app/console assets:install. The release appears to be working just fine on the target server, but the buildBootstrap, installRequirementsFile and removeSymfonyStandardFiles scripts or equivalent have not run. What are the consequences of that? Are there any app/console alternatives for them (running app/console doesn't appear to show any)?

Alternatively, are we just doing it wrong? We want to let as much work be done by the build server, as the target servers are often limited in capabilities (eg. shared hosting).

kix
  • 3,290
  • 27
  • 39
Tom Cannaerts
  • 628
  • 1
  • 5
  • 14
  • Do you end up with a app/bootstrap.php.cache file on your production machine? It's normally generated by buildBootstrap and without it the startup time will increase significantly. You can run the script from the command line. Basically, just copy it from composer.json. – Cerad Sep 12 '14 at 13:25
  • We have changed our workflow so that we do a composer install --no-scripts on the build server, and a composer install on the target server which doesn't do much more than execute the scripts (including the bootstrap.cache), as the vendor map is already up to date). – Tom Cannaerts Sep 19 '14 at 08:55

1 Answers1

0

Build

  • checkout from git
  • copy parameters for test purposes
  • do a composer install (not an update)
  • run phpunit for testing (using PHPUnit as task type)

After test if all is good an Artifact will be created, so add some tasks to remove all libraries:

  • rm -rf vendor
  • rm -rf app/cache

The build ends here.

Deploy

  • Download the artifact
  • I'm deploying with Capistrano/Capifony, so here I run it.

For your question about composer scripts don't worry if they doesn't runs, you don't need it if vendor list doesn't change. My advise in any case is to have small artifact which doesn't include libraries, and install libs with composer. If you want to do heavy work on deploy server (and not in production) you can configure Capifony with set deploy_via, :copy.

M. Foti
  • 3,156
  • 2
  • 16
  • 14
  • Why would you delete the vendor folder before creating the artifact, and how are these packages then installed on your server if they are not shipped within the artifact? – Sven Sep 12 '14 at 18:39
  • small artifacts allow me to store more builds, I run again composer install with capifony. My advice is to have a good deploy system that works well without bamboo. Bamboo is very useful to check the code (with phpunit) and store builds in case of rollback. – M. Foti Sep 12 '14 at 20:15
  • We deliberately want to vendors to be in the artifacts, as that basically gives us a complete set of files to transfer to the remote server. The idea of a release (imho) is to have all files present that you need in orde to use the code (in our case with the exception of configuration files). – Tom Cannaerts Sep 19 '14 at 08:56