A Wordpress project running in Docker integrated with Circle CI, ready to deploy from development to production, bundled with all the necessary tools.
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
.env.example
to.env
$ docker-compose up -d
to 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
- Running
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") bash
to 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
Under construction.
$ yarn run e2e
to 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_REPO
your Docker repository URLDOCKER_USER
your Docker usernameDOCKER_PASS
your Docker passwordPRODUCTION_IP
your production server IPPRODUCTION_USER
your production server userWP_THEME_NAME
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 productionAll the build tools, including versions bundled with the projectUse Gulp/Webpack for build tools to produce clean buildsImplement 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 repositoryUse 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 ComposerCSS 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
src
dist
nature to merge the application together.
Paul Stewart