Getting the best of BOA features together with the convenience of composer and GIT

[aanjaneyam]

I would like to invite views and suggestions on how to best combine composer, git and aegir to manage the codes, platforms, configuration and sites. The intention is to get the benefit of the great run time features of BOA along with the convenience of code management that comes with composer and GIT. The following comes to my mind though not sure if this would work or if I am missing something:

The below steps are done on one BOA server installed on digital ocean or Linode:

• Create development project and install code on BOA server using composer create-project ....
• Create your custom sub theme
• If needed add your custom module
• Git init to initialise the git repo on BOA server
• chmod 775 the downloaded project
• Add a new development platform on aegir panel with the code created in the first step
• Verify the development platform added above
• Add the New Development site in the development platform created above using create site on aegir panel
• Edit the .gitignore file ignoring everything except composer.json, composer. lock, custom themes directory, custom modules directory, site files in sites/dev.example.com/files and site configuration directory sites/dev.example.com/private/config
• Create remote private GIT repo on Github or Bitbucket
• Connect the local BOA repo to remote GIT repo created above using git remote add origin https://github.com/user/repo.git OR similar on bitbucket
• Add and commit the composer.json, composer. lock, custom themes directory, custom modules directory, site files in sites/dev.example.com/files and site configuration directory sites/dev.example.com/private/config on BOA server
• Push the BOA code to remote repo.
• Do the development of the development site including module or theme updates using composer update <module_name>/<theme_name>
• Verify the development site and platform
• Commit and push all the changes to the remote repo composer.json, composer. lock, custom themes, custom modules, site files in sites/dev.example.com/files and site configuration directory sites/dev.example.com/private/config

After the development has reached a stage where it need to go into production or staging:

• cd to static directory.
• Pull the code committed above from git using git clone in a new directory intended to be used new platform for staging or production site - static/
• run composer install --no-dev in the new directory
• Add new platform for staging/production using the code resulting form composer install --no-dev above
• Add a new site staging.example.com in the new platform.
• sync the configuration from the old site into the new site.
• run drush @stage.example.com updb
• verify new platform and site.

From there on carry on development on the dev site and transfer things to staging/production using git push on development platfor and pull, composer update and drush updb on staging/production site.

[aanjaneyam]

@omega8cc I would be interested in knowing about your views on the above. I am also still thinking about the sequence of last 4 steps. Over a period of time the above would become easier.

[omega8cc]

@aanjaneyam As we said in another issue, managing codebases is out of scope of BOA project. BOA provides tools you can use in many workflows, while Aegir is designed to manage Drupal sites lifecycle not codebases lifecycle. It's an important distinction. The codebase lifecycle management is thus not enforced in any way and left for the developer's preferences. It's still an interesting topic, though.

[omega8cc]

Of course Aegir provides tools and soon new interfaces to create new platforms form different sources (with Git, Composer, Drush, manual mode etc) but still it's limited to initial adding a codebase as a platform, not about managing the codebase itself between updates.

[lexsoft00]

It would be nice to have a topic for this workflow. Examples of how people use BOA to update their websites and develop.

For myself, I use GIT on the entire platform except for /sites folder. I find it easier to update a website using composer on DEV and then push those updates to production via GIT, also it makes things more clear when you need to see what composer has actually updated on the platform.