Hello WordPress Docker CircleCI
I am using the
WordPress Docker container to run the commands through as that container has the required tools and libs to build and develop this project. The idea here is to allow the host machine to remain free of such tools, only require Docker to get this party started. This way all libraries and their versions are consistent across the project and its team.
Copy and configure
$ docker-compose up -dto spin up the Docker stack
$ docker exec -it $(docker ps -qf "name=wordpress") bash -c "composer install"
$ docker exec -it $(docker ps -qf "name=wordpress") bash -c "yarn install"
$ docker exec -it $(docker ps -qf "name=wordpress") bash -c "yarn dev"
- And enjoy http://localhost
A Typical Development flow
docker exec -it $(docker ps -qf "name=wordpress") bash -c "yarn dev"will start Webpack and Gulp which will bundle and watch the necessary assets ie CSS and JS.
- Do your code changes and commit them
- A Git push to the remote origin will trigger CircleCI to build and deploy the project to production.
- No staging environment setup up as of yet
You can run
$ docker exec -it $(docker ps -qf "name=wordpress") bashto get into the contain, from which you can develop within ie run all your commands.
To mock a production style build, ie with copying files rather mounted volumes, run
$ docker-compose -f docker-compose-production-test.yml up -d --build
End to end tests
$ yarn run e2eto run all tests (@todo: fix this in the container)
In development i lazily use Docker Compose to orchestrate the containers, on production via a bash script which i guess could be done with Ansible or whatever (@todo need to finalise).
As mount bindings overrule the directory the mount points too, in development we can simply mount our code and in production the code is copied into the container for easier distribution.
Setup requires the following environment variables setup:
DOCKER_REPOyour Docker repository URL
DOCKER_USERyour Docker username
DOCKER_PASSyour Docker password
PRODUCTION_IPyour production server IP
PRODUCTION_USERyour production server user
I have added Redis as a service, just for an example, and it could be handy when there is heavy usage of WP Admin and other heavy WP query related operations going down.
- To share indentical environments between development, staging and production
- All the build tools, including versions bundled with the project
- Use Gulp/Webpack for build tools to produce clean builds
- Implement JS linting to help increase code quality and reduce bugs
- Implement end to end testing to ensure functionality works as intended
- Attached to a Slack channel to notify other project members of the build and its movements.
- Implement PHP unit testing
- To be able to deploy by simply committing work to the remote git repository
- Use a docker registry to hold the application, so project deployment and rebuilds are easy and require no local project to be built
- To use branches/tags for staging and production versions of the application
- To get CI build time as fast as possible by caching steps, building my own image with the tools required
- To utilize some logging services for PHP, Nginx ie Papertrail etc
- Fetch WordPress, plugins and other PHP libs via Composer
- CSS and JS formated with Prettier
Putting WP in a subdirectory? Would simplify things, but WP complains ie multisite and some plugins when this happens, hence my decision to have a
distnature to merge the application together.