Development Life Cycle

Developing a website poses a series of challenges that can occur in various stages of the process, ranging from building a dev environment to deploying it live. At Presslabs, we offer free development sites, to offer our customers a safe environment for testing new features, as well as investigating other site issues. Find out more about development – stage – production environments basics and the benefits of dev sites on our blog .

The Presslabs platform was build around git and each site hosted by Presslabs has a git repository associated with it. Regarding the development sites, they can be set up in two ways:

• the production and development site are located on separate repositories
• the production and development site are located on the same repository, but on different branches.

You can ask our Support team to set your development site the way you prefer it.

Depending on your chosen development site setup, there are two recommended development life cycles. Both underline that you should first make changes on a local environment, or on your development instance, and only after proper testing push them to the live site.

In this way, you ensure that if something happens, it will happen to the dev site and not the live one.

Case 1: The production and the development sites are on separate repositories

Each repository comes with a Docker file for local development. You can follow these steps to set up the Docker environment corresponding to your site. This way, you can develop and test locally, and, when you are satisfied, merge the code with the master branch and push it to the live site.

Like we said earlier, pushing to a site’s git master branch means deploying it to live, and each site comes with its own git repository. We will use this to our advantage to create the well-known development pipeline: local - staging - production. In order to do this, you need two Presslabs sites, one for production (site) and one for staging (dev-site), while following these steps (replace site and dev-site with the corresponding IDs from your Presslabs account):

1. Clone the site

git clone -o prod git@git.presslabs.net:username/site.git
cd site

2. Add stage remote

git remote add stage git@git.presslabs.net:username/dev-site.git
git fetch stage

3. Push master by default to stage

git config branch.master.remote stage

4. Create the feature branch

git checkout -b feature-name

Now, you can develop the new feature locally and test it on the Docker setup described above.

5. Merge the feature branch into master and push it to staging

git checkout master
git merge feature-name
git push stage

Now, you can test your changes on the staging site (dev-site), which is identical with the production site from the environment point of view (caching, security restrictions etc.).

6. Push the changes to live when ready

git push prod

Following this guideline, you can always push where you want to by using git push prod and git push stage.

Also, if you update plugins directly on production, you can always create a local production branch with git checkout -b production prod/master and merge it with your local master. This way you can merge remote changes from production or stage with local ones.

Case 2: The production and development site are on the same repository, but on different branches

This development site setup means that you can have 2 branches on the same repository: master (which is connected to the live site) and develop (connected to the development site).

Step 1: Switch to develop branch

Clone your code locally:

git clone https://git.presslabs.net/username/site.git
cd site

Switch to the develop branch:

git checkout develop

Ensure you have all the changes from the repo:

git pull origin develop

Step 2: Push the changes to the development site

Do the code changes that you want to do and test them on the local environment. When everything is ready and working as expected on the local environment, you can push these changes to the development site.

Here’s how to do it:

Check out the changes that have been made

git status

You can ignore from this list the wordpress folder, as that is only used for your local setup.

You can also ensure you’re on the develop branch, so you won’t send the changes directly into production:

git branch

Prepare all changes from the entire wp-content folder to be sent to the development site

git add -A wp-content/

-A means that you’ll also add the files that need to be removed ( e.g. in case you have deleted some files that are not needed). In case you want to send for testing only one file, then you should only add that file. For example:

git add wp-content/themes/yourthemename/style.css

Now that the modified files are added, you need to commit them:

git commit -m "Here's the commit message"

In the commit message, it’s good to say what you have changed, in order to have an easy way to revert, if needed.

The final step is to get the changes pushed

git push origin develop

After this command is executed, you can check how everything looks on the dev site.

Step 3. Push the changes on the production site

If everything is OK on the dev site, then you can push the changes in production:

First, switch to the master branch:

git checkout master

Then, ensure you have all the changes:

git pull origin master

Merge the changes from develop into master:

git merge develop

Then, push all the changes to the production site:

git push origin master