Hi @trevan ,
I’m pretty new to flywheel hosting and would appreciate any feedback on where things could be improved, especially when considering the features for flywheel hosting. Following approach was done when we haven’t had a bulk plan at geflywheel.
A new project gets created in GitLab, along with a configuration for a GitLab runner (doing some linting stuff, no unit tests, deploying the theme folder to the correct server/folder, installing WordPress plugins via composer and activating them via wp-cli).
The basic structure of our project looks like this:
/dist #folder to hold minified and uglified theme and plugins, ready to be published
In terms of npm/gulp we have taks like
prod: gulp cleanup && gulp-build-prod
dev: gulp build-dev // also fires a watcher with browsersync reload
install:plugins: // several tasks that copies everything from /src/plugins to
build/app/public/wp-content/plugins. Afterwards it runs composer update to
update public plugins and wp-cli to activate all plugins
When a user starts developing, we usually have this workflow:
- pulling the latest changes from GitLab
npm run install:plugins to get/update/activate all required wp plugins
- pulling the latest DB/media files from live to local via migrate db
npm run dev
- Working on the theme within a feature branch
In that scenario, the watcher tasks copy all the files to the corresponding build-folder (the one where local is pointing to) and browsersync works as expected.
Once the developer is done, he or she pushes their changes to Gitlab, create a merge request and once the review is done and got accepted, the shared runner kicks in.
Shared runner (runs on the same server as the WordPress installation)
That one is run after every merge from feature-branch into master and does nothing else than executing npm scripts:
- npm run lint for checking css and js files
- npm run prod to build the files for a production server
- rsync theme and plugins folder to the correct Wordpress-installation
- executes composer update (for public plugins)
- executes wp-cli plugin install (for our custom-plugins)
- executes wp-cli activate
That way, we get the very same result for every developer and pushing to our stage-server is done completely automatically. When we create a TAG in Gitlab, that particular TAG gets deployed to a QA server where a client can test the website without being interrupted by new continuous deployments.
Note: Maybe this is a little bit of an overkill. But theme development could sometimes be so boring and switching on our techie goggles helps to make a seemingly boring project way more exciting (-:
What do you think and do you guys have any tips on how to better include local by flywheel and the newly bought bulk plan?