Make sure that you've taken a look at the following tutorial(s) before you continue:
- $300 free trial. How to use it wisely ?
- Let's get MySQL up and running on Kubernetes
- Let's get WordPress up and running on Kubernetes
- SSL secured WordPress website on Kubernetes
- Create git repository and push your code
- Development environment on Kubernetes
In this tutorial example.com will be used for project's domain name and example for project name and some prefixes. Commands presented in this tutorial should be executed from the root of tutorial's git repository.
By now you should have your secure WordPress website up and running. Your development environment should already be configured and available
You are going to learn
- how to use git branches
- what example workflow scenario could look like
- how to track WordPress plugin's code changes on update
- How to organize your software development workflow ?
- 1Learn about git branching strategies
- 2Example workflow scenario - Implementation
- 3Example workflow scenario - Testing and fixing
- 4Example workflow scenario - Deployment
- 5Better workflow with Merge Requests on GitLab
- 6Push WordPress update result to repository
- 7Things to think about
How to organize your software development workflow ?
For convenient project workflow I suggest using git’s branches on development and production environments. Usually several branches are used in one project. Some of those branches are more stable than others and are modified less often (eg. master). Other branches are used daily and are modified more frequently (eg. develop). In this tutorial production environment uses stable master branch but have a look at GitLab flow.
There are two strategies for branching with git.
You create a branch that will not be deleted. For example you create a branch called development. All the changes will be added to development branch first. Only then changes from this branch will be merged to stable master branch.
They are short-lived branches that are created and used for a single feature or task (eg. an issue from tracking system). Example underneath uses topic/feature branches. With Git it is a common practice to create, modify, merge and delete branches even several times a day because it is not expensive unlike with other source code management solutions.
You can mix strategies to achieve the result you find convenient.
New issue is assigned to you - #69 Homepage – Logo needs to be replaced with a photo of a monkey holding a keyboard
You do not have current development environment so you create it. On you local machine you create a topic branch for your WordPress project and switch to it
You change the logo and commit the code changes
Remember to mention issue’s number using hash # inside the message. It is a good habit to copy over the title of the issue as well. If the title is too long just shorten it. Push the local branch to the origin and add upstream reference
GitLab will give you a link that you can use to create a new merge request. Managing merge requests is a great feature if more than one person is working on a project. For the purpose of this tutorial we will do merges without using this feature.
At the end of the output you should get a message saying
Branch iss69 set up to track remote branch iss69 from origin.
You need to verify that the homepage really displays a monkey holding a keyboard. When the changes are pushed to development environment you can let your boss see them before they go to production.
Connect to your development environment Pod
Before making any changes verify that you are using the correct Pod
Go to your project’s working directory and fetch the changes you have just pushed to origin from your local machine
Switch development environment to your issue’s topic branch
Bam! Your development environment now has changes from the origin.
Buuut waaait ... Oh no! The photo of the monkey holding a keyboard is upside down.
You fix it on you local machine, commit the changes and push to origin.
Notice the Close #69 in the message. This message committed to GitLab will automatically close issue #69.
Now you need to test your code again so you pull the modified code on your development environment.
Everything works well this time. Monkey photo is not upside down anymore. Changes have been accepted by the boss and you no longer need a copy of iss69 branch on your development environment. Switch to master branch before you delete the local iss69 branch.
Topic branches are usually deleted after they've been merged. For now delete copy of the branch that is on development environment
If anyone else has made changes to the master while you were working on the iss69 branch then you will have to merge those changes to iss69 branch first.
On your local machine check first if you are using iss69 branch and then merge changes from master to iss69 branch
There were no conflicts and now your iss69 branch contains your fixes for the logo problem and any new code from master created by your teammates.
Everything looks great and you are ready to merge the changes in iss69 to master branch which is used as the base for production environment.
On your local machine switch to master branch
Merge all the changes from iss69 branch to master.
--no-ff flag basically groups together commits done in the topic branch in one commit. This way you can mark that the branch existed and was merged. It also looks much cleaner to your team members when they use
git log --graph or view commits history in their IDE. You can make a thousand commits on your topic branch and then turn them into one.
Copy of iss69 branch has already been deleted from development environment. Get rid of the topic issue first on the origin and then locally.
Push to origin master
Connect to you production environment Pod
Inside your project's working directory run
Bam! The changes appear on the production environment. You've avoided a production error by testing your changes on the development environment first.
Logo looks really good on the production environment and your boss tells you that you did a great job. Company's revenues increase 7.6% that month. You get Monkey with a keyboard of the month award that comes with a significant bonus. Your dad finds out about it from the local newspaper and says to you the words that you wanted to hear your whole life:
I am proud of you son
You know ... just a hypothetical workflow scenario ...
Setting up development environments is not a hassle anymore but rather a set of repeatable actions. You could potentially set up another one right now to work on some long-running branch that will be integrated in a year. Maybe you need one for some proof of concept ?
Remember that adding new (sub)domains to Let's Encrypt should never ever be done in a batch. If you need plenty of sub-domains then add them slowly two or three at a time. Let's Encrypt has Rate Limits and if you exceed them it will be a huge pain in the ...
GitLab helps to simplify and organize software development workflow. It does so by implementing the concept of Merge Requests (MR). MR is similar to an issue. It has a title, description and people who are assigned to it. Difference is that it is mostly used after you work on the feature is finished and only to review the code and merge it.
When you get an issue assigned you can create feature branch and a Merge Request with one click on GitLab. View the issue on GitLab and click Create merge request button. You will be transferred to your newly created MR view. GitLab will also create branch for your feature and you can check it out from origin. To view available branches go to Repository tab on GitLab or simply use
You can also create Merge Requests after you've created a branch yourself.
Let's talk about MR some more. Take a look at the title of your new MR. It starts with WIP: and this blocks MR from merging. WIP stands for Work In Progress. Only after removing it from the title merge will be possible. You can quickly add WIP by clicking a button or adding a comment containing GitLab quick action
Usually before work is done Merge Request is assigned to the person working on the feature. When you are finished working on the issue you re-assign the Merge Request to someone else for code review. GitLab has nice tools for comparing code diffs and code review related discussion. You can comment on specific lines of code etc.
If everything is fine then WIP status of the MR can be removed. You can do all of this conveniently from MR view on GitLab with one click. With WIP status gone you are able to merge changes. When you merge you can select the option to remove source branch after the merge is finished. You also have filled MR description that will auto-close the issue (Close #69). If I can count you need 3 clicks on GitLab to merge your changes, close the issue and remove the topic/feature branch and one more to close the MR.
If Internet Explorer has enough courage to ask me if it can be my default browser then I believe I have enough courage to say
GitLab ... I think I love you
Pushing changes done by WordPress plugin or theme update to the repository is a useful thing. Let's say that you want to track every change that the author of the plugin or a theme makes. Maybe you have a piece of your own code somewhere in a third party code and every time you update it you lose the changes. Re-introducing the changes every time can become cumbersome really fast.
Let's assume the following. All plugin's code needs to be pushed to the repository before you update the plugin. Then you want to update the plugin using WordPress and check what has changed between versions.
If you have added that plugin to
.gitignore you will need to remove the entry first. If you are using GitLab deploy keys then remember that key needs to have write access allowed for this to work.
Now you probably want to push plugin's code to origin
After that you can update the plugin using WordPress. Check which files have been changed by plugin's update
Add any new files and commit the changes made by the update to git repository. Push to origin again to have updated plugin's code in your remote repository.
It does not work with all the plugins. Some of them can have complex logic and create some file structure outside of their own directory.
Additionally there is always a risk that an update of the plugin performs some database operations. When you merge changes to your master then the changes made to the database by the update might be missing. Usually turning the plugin on and off fixes the issues but that is not always the case.
Removing GitLab ssh-keys volume from production Deployment and using your credentials instead
You will rarely need to push something from production Pod to your repository. Most of the pushing and pulling will from now on happen on your development environment. Having an open access to your GitLab repository directly from your production server is just asking for trouble. Just one word of advice. GitLab username is your email address so typing it might get boring too. Alternative option is presented below
Using read-only deploy key on production environment
If you will never push anything from your production Pod to the repository then you might want to consider using a separate read-only deploy key on production. On GitLab select a project. Go to SettingsRepository. Find Deploy Keys section and click Expand and do not check Write access allowed when you create the key. Create a Secret out of it and use it in your production Deployment.