Team Members:
- Nikhil Katre ([email protected])
- Pengyu Li ([email protected])
Submission: Milestone#Special
Submission Files:
- README.md
- Project Files
- Project Presentation Video ( Milestone Special starts from 3:48)
- Introduce a waterfall staging component.
- Introduce resilience testing (chaos monkey).
- Implement a new deployment strategy.
- Implement a more advanced fuzzing/test generation technique.
- Create a novel IaaS/PaaS/app (e.g., BrowserStack, a service to make it easy to do UI testing of a deployed app on many browser versions).
Milestone#Special is evaluated based on the following Evaluation Parameters:
- Novelty: 25%
- Implementation: 25%
- Project Presentation: 50%
For Milestone Special we have implemented a new deployment strategy called three stage deployment OR Red Yellow Green Deployment.
-
Stage I: The developers frequently test and deploy code to the Development Sandbox, which handles frequent development environment.
-
Stage II: The QA and UAT tests are handled in 2nd stage called Pre-Production Stage, which is a controlled development and testing enviorment. At this stage we have used Jenkins as built and continuous integration tool. Jenkins constantly monitor remote git repositories for any changes. For every change it will build the project automatically.
-
Stage III: after exhaustive development and testing, every successfull built by Jenkins is automatically pushed to highly controlled Production Sandbox, where it is constantly monitored using parameters such as traffic utilization, CPU usage, Memory usage and etc.
We have used 2 VCL machines for Stage I and Stage III servers. Stage II server is a local machine
- Stage I (Development Sandbox)= 152.7.99.118
- Stage II (Pre-Production Sandbox) = local machine
- Stage III (Production Sandbox) = 152.46.20.173
Install the following ON ALL THREE INSTANCES (Stage I, II and III) to achieve this Milestone
- Download and install java
- Download and Install git
- ON ALL THREE INSTANCES (master, canary1 and canary2) allow all traffic option selected from security group in AWS
In addition, every stage will have individual tools and development environments which are stated below according to every stage's individual requirement.
Stage I: Development Sandbox
This development sandbox is used by developers. For the first stage the developer would build project using DEVELOPER tools such as git, eclipse, eclipse plugins such as find bugs for testing Every successful built would be pushed to remote git repository.
The following tools are installed at Stage I:
- Eclipse
- Eclipse J2EE plugin with tomcat server to run Maven Project
- Eclipse FindBug plugin for testing and static analysis
Stage II: Pre-Production Sandbox
At the 2nd stage, Jenkins would is set up which is contantly monitoring the remote repository for any changes. For every change it builds automatically and every successfull build is then push to the production environment using git hooks
The following tools are installed at Stage II:
- Jenkins
- Jenkins plugins such as
Plugins installed for this milestone:
- GitHub Plugin
- NodeLabel Parameter Plugin
- Maven Project Plugin
- Config File Provider Plugin
- Git Plugin
- Git Client Plugin
- Managed Script Plugin
- GitHub API Plugin
- FindBugs
Stage III: Production Sandbox
At the 3rd stage, the deployed application would be constantly monitored remotely using parameters such as CPU usage, Memory usage and etc.
The following tool is installed at Stage II:
We have used remmina to remote rdp into Ubuntu environments (development and production sandbox) from Ubuntu environment (pre-production sandbox)
- Developers would use eclipse to develop the application.
- Eclipse plugins such as FindBugs can be used for testing and static analysis.
- Below is the image of eclipse with FindBugs plugin and other necessary plugins
- Developers would build the application locally by setting up a run environment for the application.
- In this case, for J2EE maven project, we built the application locally using tomcat server
- The output after building the application is as follows
- If the code is bug-free, developers would push this code to remote git repository using simple git commands such as:
git add .
git commit -m "{message}"
git push <remote_branch> <local_branch>
- In this case, Milestone#Special is the remote git repository
- Jenkins is set up to poll remote git repository every 1 minute. If there is a new commit in the remote repository then Jenkins automatically pulls the new commits and builds the project locally.
- If the project is successfully built then the code is pushed to the production server using git hook
- Jenkins is configured to execute a shell script after each successful built to push the code to production server
-
The following are the contents of the script pushToProduction.sh which would push the code to Production server after successful Jenkins built
-
Console Output of Built of Jenkins which is triggered due to change in remote repository
We made production server remote repository to pre-production server. We will use git to deploy the code remotely using post-receive hook
in bare git repository.
The following steps should be followed to make production server as remote repository of pre-production server.
- Add rsa_pub key with ssh
$ ssh-keygen (Generate ssh key)
$ ssh-add
- Add git remote at Pre-Production server
$ git remote add production ssh://152.7.99.118/home/nkatre/production.git
$ cd $HOME
$ mkdir production.git
$ mkdir production.www
$ cd production.git
$ git init --bare
$ cat > hooks/post-receive
#!/bin/sh
GIT_WORK_TREE=/home/nkatre/production-www/ git checkout -f
Make post-receive executable:
$ chmod +x hooks/post-receive
OUTPUT:
- Manually Pushing to production repository output. The same task is achieved using Jenkins by pushToProduction.sh script
After deployment of new version on Production Sandbox, we are remotely monitoring the health of this server by parameters such as CPU usage, memory utilization, Fault number and Alert number.
One can run the following commands to check the status of the server using monitor.
- Start monitor node main.js
- Open monitor in a browser xdg-open www/index.html
We have also set a threshold parameter to simulate server failure condition. We use two paramaters which are constantly monitored.
1. Memory Usage
2. CPU Usage
ALERT:
If the memory usage is above 30 and the CPU usage is above 20 then alert would be set off. FAILURE:
If the memory usage if above 70 and the CPU usage is above 50 then the server would fail.
To demonstrate this, follow the below mentioned images:
- This image demonstrates alert when threshold values are crossed. Here the alert count is 1 (alert is set off) since the CPU usage is 33 which is above 20 and the memory usage is 45 which is above 30.
- This image demonstrates that when the threshold values for failure are crossed. In this image since the memory usage is above 70 and the CPU usage is above 50 hence the server has crossed the failure threshold and has failed.
- We have created a small video demonstrating the working of Milestone Special.
- Link to Presentation video (Milestone Special starts from 3:48)