The ITIS Web Services Deployment application is a tool developed specifically for help our developers deploy content from our development environments to our Production web hosting environments. This manual is provided to give you all of the information you will need to perform that task.
ITIS Web Services uses a three tiered Development, Quality Assurance, Production environment. This means that regardless of your chosen web environment, you will have all three tiers of servers at your disposal.
Our Development tier allows our developers access to the resources needed to actively develop content. Some of these systems will provide shared drives or even local account access. This varies according to the environment so please check with your friendly neighborhood Web Admins for more information.
Our Quality Assurance (QA) tier does not offer developers direct access to system resources. This is used to test content for security vulnerabilities, load handling, and possible bugs. The QA environment is also used as a staging area so multiple developers may work on subsections of a large site in the Development environment and pool their collective changes over time before testing or deploying to Production. Vulnerability scans are available free of charge for any web content in this tier to any developers who request it. Developers are encouraged to deploy their content from our Development tier to our QA tier and perform these tests before deploying content to our Production tier.
The Production tier is where the our developers’ content is hosted for the general public. People from all over the world have access to the content on these servers and this is our primary web presence at Purdue University.
The deployment model we have chosen requires that our developers deploy content from the Development tier to the QA tier and from the QA tier to the Production tier.
The Deployment Application
Access to the ITIS Web Services Deployment application is restricted to some Purdue IP addresses. If you wish to use this tool from an off-campus computer, you will be required use VPN to gain access to the application. Access is also restricted to developers who are authorized to work on content. Developers are granted access to modify and deploy content based on the content owner’s authorization requests to ITIS Web Services. If you wish to have access to use the deployment tool to deploy content, ITIS Web Services *MUST* receive a request from an authorized content owner on your behalf.
To use the deployment application, direct your browser to: https://deploy.itap.purdue.edu
Click on the “Get Started” button and enter your career account credentials. Once inside the deployment application, you will be allowed to select the site you wish to deploy from a drop down selection list. The sites listed are the destination sites, or the sites to which your content will be deployed. For instance, if you are the developer for www.fakesite.purdue.edu, your list should contain www.fakesite.purdue.edu AND qa.fakesite.purdue.edu. If you deploy qa.fakesite.purdue.edu, content will be copied from the development server to the QA server. If you deploy www.fakesite.purdue.edu, content will be copied from the QA server to the production server.
The basic deployment process works in three steps.
- Select your content to deploy
- Submit your selection
- Confirm the submission
Select your content. You may select your content by selecting the site you wish to deploy and if you are using the Advanced Deploy, you may also chose any number of folders or files to deploy within the site.
Click on the “Deploy” button to enter the deployment process. This will do a mock deploy. That is, it will pretend to copy the requested content to the target server, but wont actually do it. But it will send you email and show you what would have happened if it really had copied the files. This allows you to verify that the files moving to the target server are what you expect before committing. If you don’t like what you see, you may cancel to return to the content selection stage to try again.
It is important to note that the Deploy Tool will only move files from one server to another if they are different! This means that if a folder contains 20 files on Dev and doesn’t even exist on QA, deploying that folder to QA will result in the folder being created and 20 files being transferred. If you later modify a single file in that folder on Dev and deploy it to QA again, only that one file will be transferred. This same behavior will occur in QA to Prod deployments as well.
Once you’re happy with the results of the mock deployment, you may proceed with the actual deployment by clicking on the “Confirm” button on the mock deploy results page. This will really copy the files this time, so please be certain that you have selected the correct content.
Simple deployment involves only one option and that is the site you wish to deploy. Once you have chosen your site, click on the “Deploy” button to begin the deployment process.
Advanced deployment adds more power but also more complexity. When you chose to do Advanced deployment, you chose to use the full feature set of the deployment application. Advanced deployment allows you to browse the actual filesystem of the development or QA server which is the source of the files to be copied to your QA or production server, respectively. For instance, if you want to deploy www.fakesite.purdue.edu, you will be able to navigate the directory structure of qa.fakesite.purdue.edu to choose your files for deployment.
Once you have selected the file or directory you wish to deploy, click the “>>” button to move it to the right-hand box. If you find that you have moved the wrong file into the right-hand box, select that file in the right-hand box and click the “<<” button to move it to the left box. Both of these boxes are Multiple Select boxes so you may choose any number of items in each before performing the desired action. Both files and directories may be chosen, even at the same time.
Sometimes you want to deploy a folder and all of its contents. Sometimes, you want to deploy the folder’s top level files without affecting the contents of its subfolders. This is where the Recursive Deploy option comes into play. The Recursive Deploy option allows you to specify whether or not a folder will be recursed. That is, whether or not all of its subfolders and their contents including their subfolders and so on will be selected. The default option is to use recursion. Most of the time, most developers want to deploy an entire folder instead of selecting only the few scattered items within it that have changed. However, should you decide you do not want to perform a recursive deploy, simply un-check the Recursive Deploy checkbox option.
You may still be confused, or not confused but wondering, “Why would I ever want to turn off recursion?” Here is an example. Let’s say you have a folder named “Testing.” Inside this folder you have a folder named “images” and a folder named “stuff.” You have removed the “stuff” in the Development environment. You want it removed from QA and Production. Here are the steps:
- Choose to perform an “Advanced” deploy
- Select the QA site for deployment
- select the “Testing” folder and place it in the right-hand selection box.
- Uncheck the “Recursive Deploy” checkbox
- Click “Deploy”
- Confirm that the results are what you want
- Click “Confirm”
This will cause the folder named “stuff” to be removed from the QA site. It may update the time/date stamp on the “images” folder but will not update the contents of the “images” folder. Now, repeat the process for the Production site and you will remove the “stuff” folder there as well.
There are a few preferences that can be changed with regards to deploy. As time goes on, more and more preferences will be available to you. For now, the preferences that are available are:
The “Interface” preference refers to whether or not you want the deployment application to start with the Advanced or Simple Deployment Interface when you visit the site. By default, everyone starts with the Simple Deployment Interface.
The “Verbose” preference determines whether or not you receive full detailed output from the mock deploment. By default, the preference is to not see the full detail of the mock deployment output.
We hope to deliver a page that will allow you to change your preferences at will in the near future. Until then, if you wish to change your preferences, you may request the change from the Web Admins.
How It Works
This is the behind the scenes section for those who wish to know a little more detail about the deploy tool’s inner workings. The most important piece of information is that the hard work of synchronizing the files is done by the common Unix utility, rsync. rsync will make sure that any two directories or files are synchronized using a source-to-destination fashion. For instance, when deploying a production web site, we specify the QA server as the source and the Production server as the destination.
The settings we use for rsync make it check for two differences between files. These differences are the time/date stamp and file size. If either of these values differs between two files, rsync will copy the file from the source to the destination. This is done for each file being polled.