Deploying your first change

In the Cloning the application to the local machine recipe, you learned how to clone an OpenShift application Git repository using the git clone command. The next logical step after cloning the repository is to make a change, commit it, and finally deploy it. In this recipe, you will learn how to deploy the source code changes to OpenShift applications.

Getting ready

To step through this recipe, you will need Git installed on your local machine.

How to do it…

Perform the following steps to deploy your first change:

1. Go to the OpenShift web console and navigate to the PHP 5.4 application creation page at https://openshift.redhat.com/app/console/application_type/cart!php-5.4.
2. Enter the name of the application. I have used myapp as the application name.
3. Click on the Create Application button to create a new application.
4. Clone the application's Git repository on your local machine by following the steps mentioned in the Cloning the application to the local machine recipe.
5. Open the index.php file inside the application source code root directory. Go to the following line of code in index.php:

   <h1>Welcome to your PHP application on OpenShift</h1>

   Replace the preceding line of code with this:

   <h1>Updated the application</h1>

6. Commit the change to the local repository using Git:

   $ git commit -am 'modified index.php'
   

7. Push the changes to the remote repository hosted on the OpenShift application gear using the following Git command:

   $ git push origin master
   

8. After git push successfully completes, open the http://myapp-{domain-name}.rhcloud.com/ application in your favorite browser. You will see your first change.

How it works…

The OpenShift deployment process is based around Git. From step 1 to step 4, you created a PHP 5.4 application using the web console and cloned the application on your local machine. In step 5, you made a simple change to the index.php file. This change has not yet been committed to the local repository. Git, being a distributed version control system, has a concept of local and remote repositories. You can continue working (making changes and committing them) on your local machine as long as you want, and when you are ready, you can push the changes to the remote Git repository.

In step 6, you committed the change to your local Git repository using the git commit command. You used the -a and -m options. The -a option tells the git command to automatically stage the modified and deleted files, but new files are not touched. To commit a new file, you have to first stage the file using the git add command and then commit it:

$ git add test.html
$ git commit -m 'new html file'

Step 7 pushes the local commits to a remote repository. When you clone a repository, the cloned repository maintains a link back to its parent repository via a remote called origin. A remote is a handle or reference to another Git repository. The remote information is stored in a configuration file called config under the .git folder. You can open the .git/config file and view the origin remote information as follows:

[remote 'origin']
  url = ssh://[e-mail]/~/git/blog.git/
  fetch = +refs/heads/*:refs/remotes/origin/*

As shown in the preceding code, a remote consists of two different parts. The url part is the name of the remote repository in the form of a URL. The fetch part specifies how a reference should be mapped from the namespace of one repository into that of another.

The output of the git push command is as follows:

$ git push origin master
Counting objects: 7, done.
Compressing objects: 100% (4/4), done.
Writing objects: 100% (4/4), 404 bytes | 0 bytes/s, done.
Total 4 (delta 3), reused 0 (delta 0)
remote: Stopping PHP cartridge
remote: Waiting for stop to finish
remote: Stopping MySQL cartridge
remote: Stopping PHPMyAdmin cartridge
remote: Waiting for stop to finish
remote: Building git ref 'master', commit 3933f99
remote: Building PHP cartridge
remote: Preparing build for deployment
remote: Deployment id is b78e5efd
remote: Activating deployment
remote: Starting MySQL cartridge
remote: Starting PHPMyAdmin cartridge
remote: Database already configured.
remote: Starting PHP cartridge
remote: Result: success
remote: Activation status: success
remote: Deployment completed with status: success
To ssh://[e-mail]/~/git/blog.git/
   e83c2a7..3933f99  master -> master

This is how the process works:

1. Git takes the master branch changes, compresses them, and transfers all the missing objects from your local repository to the remote repository named origin.
2. Next, a pre-receive action hook is invoked on the application gear. Git hooks are custom scripts, which Git will run at specific events like push. You can write scripts in bash, Perl, Python, Ruby, or whatever you have. The pre-receive hook receives a list of all (new or old) the refs that are to be updated. The pre-receive action hook in the application gear Git repository stops the PHP and other cartridges, checks the deployment integrity, and configures the deployment metadata.
3. Lastly, the postreceive action hook is invoked on the application gear. It receives a list of all the updated refs. The postreceive action hook in the application gear Git repository archives the application repository, builds the application, starts the PHP and other cartridges, and then finally deploys the application.

There's more…

Instead of using the git push origin master command, you can also use git push. The origin part is the default remote and master is the default branch, so they are not required.

See also

• The Cloning the application to the local machine recipe