With the Live Development mode, you can make changes locally and see the results right away in your Cloud Platform development environment. This document describes how to take the changes you have made locally and eventually deploy them on your production application. For information about enabling or disabling the Live Development mode, see Using the Live Development mode.

When you first enable Live Development mode for a Cloud Platform Development environment, Cloud Platform checks out the code branch that is currently deployed on your Dev environment into your ~/dev/livedev directory, making it a local version of whatever branch was deployed in that environment. All requests for your application’s development environment now refer to these files as long as you leave Live Development enabled. While you can enable Live Development for other non-production environments, the best practice is to use it only on Development environments.

Before you enable Live Development mode, make sure that your environment has a branch (ideally, the master branch) and not a tag deployed. You cannot commit your changes to a tag.

Enabling Live Development on an environment can slow the response times of your Drupal application. Live Development uses the Cloud Platform network file system to ensure your code is reachable from the infrastructure. Since a network file system is not well-suited for code execution, using Live Development can affect the performance of your application. Therefore, we recommend disabling Live Development when you are done with your changes.

Consider a typical use case where you have installed or imported a Drupal application into the Development environment of a Cloud Platform application. The master branch is deployed in Development, so that you can see commits to the master branch quickly. Your Environments page looks something like this, displaying the master branch deployed in the Dev environment:

1. Enable Live Development for the Development environment.

   Your Environments page now displays the Live Development branch deployed in the Development environment.

2. Sign in to your infrastructure, as described in Accessing your infrastructure using SSH.

3. Navigate to the live development directory:

   copy

   cd ~/dev/livedev/docroot

Suppose that you make a change to some files. For example, you might update a module or make various CSS file changes. You have made these changes in your local code repository, and you can see them immediately in your Cloud Platform application, but you then need to get these changes back into your Cloud Platform code repository so that they can be incorporated into future production releases of your code. To do this, you need to commit the changes to your Cloud Platform application’s repository. You will accomplish these steps:

1. Identify the uncommitted changes.
2. Commit the desired changes.
3. Disable Live Development mode.
4. Test your code and deploy it on your Staging or Production environments.

Committing your changes in Git

The first step is to use your version control system to show you all the changes since your last commit. You may not even remember all of the changes, so it is important to review what they all were, before proceeding. Enter the following command:

git status --short --untracked-files=all --ignored

Now review the feedback you get from this command as to what the uncommitted new and changed files are. Uncommitted new files look like this:

?? docroot/kb1.txt

You can commit the new file with commands similar to the following:

git add kb1.txt git commit -m "New file 'docroot/kb1.txt'" kb1.txt

Uncommitted changed files look like this:

M docroot/.htaccess

You can commit the changed file with the following command:

git commit -m "Added redirect for legacy URL http://example.com/about-us" .htaccess

git push origin master

Making your changes live

After you have committed your changes in your Development environment to your application’s code repository, you need to disable Live Development mode to make your changes go live on your Staging or Production environments.

After you leave the Live Development mode, you can drag your code to the Stage environment, test it, and eventually drag it to the Prod environment when you are ready to deploy it on your live, production application.

This completes one cycle of using the Live Development mode in the Development environment.

Live Development workflow

Enabling Live Development on an environment can slow the response times of your Drupal application. Live Development uses the Cloud Platform network file system to ensure your code is reachable from the infrastructure. Since a network file system is not well-suited for code execution, using Live Development can affect the performance of your application. Therefore, we recommend disabling Live Development when you are done with your changes.

Consider a typical use case where you have installed or imported a Drupal application into the Development environment of a Cloud Platform application. The master branch is deployed in Development, so that you can see commits to the master branch quickly. Your Environments page looks something like this, displaying the master branch deployed in the Dev environment:

1. Enable Live Development for the Development environment.

   Your Environments page now displays the Live Development branch deployed in the Development environment.

2. Sign in to your infrastructure, as described in Accessing your infrastructure using SSH.

3. Navigate to the live development directory:

   copy

   cd ~/dev/livedev/docroot

Suppose that you make a change to some files. For example, you might update a module or make various CSS file changes. You have made these changes in your local code repository, and you can see them immediately in your Cloud Platform application, but you then need to get these changes back into your Cloud Platform code repository so that they can be incorporated into future production releases of your code. To do this, you need to commit the changes to your Cloud Platform application’s repository. You will accomplish these steps:

1. Identify the uncommitted changes.
2. Commit the desired changes.
3. Disable Live Development mode.
4. Test your code and deploy it on your Staging or Production environments.

Committing your changes in Git

The first step is to use your version control system to show you all the changes since your last commit. You may not even remember all of the changes, so it is important to review what they all were, before proceeding. Enter the following command:

Now review the feedback you get from this command as to what the uncommitted new and changed files are. Uncommitted new files look like this:

You can commit the new file with commands similar to the following:

Uncommitted changed files look like this:

You can commit the changed file with the following command:

Making your changes live

After you have committed your changes in your Development environment to your application’s code repository, you need to disable Live Development mode to make your changes go live on your Staging or Production environments.

After you leave the Live Development mode, you can drag your code to the Stage environment, test it, and eventually drag it to the Prod environment when you are ready to deploy it on your live, production application.

This completes one cycle of using the Live Development mode in the Development environment.