10. 🚀 Deployment & Operations

10.1 Deployment Workflow

Understanding the workflow from development to operations of HONGIKINGAN CMS is important for efficient project management. The typical workflow is as follows.

10.1.1 Development Server Deployment

📝 Source Code Commit

Commit completed development code to SVN/Git repository

🔨 Build & Packaging

Build project using Maven
Generate WAR file

🚀 Development Server Deployment

Deploy WAR file to development server
Modify configuration files according to environment

🧪 Development Server Testing

Functional testing
Integration testing
Performance testing

10.1.2 Test Server Deployment

🚀 Test Server Deployment

Deploy WAR file to test server
Modify configuration files according to environment

🔍 QA Testing

Functional testing
Regression testing
Performance testing
Security testing

🔧 Issue Resolution

Fix discovered issues
Redeploy and test fixes

10.1.3 Production Server Deployment

📋 Deployment Planning

Establish deployment schedule and procedures
Establish rollback plan

🚀 Production Server Deployment

Deploy WAR file to production server
Modify configuration files according to environment
Apply database schema changes

✅ Deployment Verification

Verify major functionality operation
Check monitoring systems

10.1.4 Operations & Maintenance

📊 Monitoring

System status monitoring
Log monitoring
Performance monitoring

🚨 Issue Response

Respond to issues occurring during operations
Apply emergency patches

🔧 Regular Maintenance

Apply regular patches
Performance optimization
Security updates

10.2 Deployment Strategies

Let's explore strategies for effectively deploying HONGIKINGAN CMS.

10.2.1 Manual Deployment

The most basic deployment method, manually deploying WAR files to the server.

Deployment Script Example (Suggested Code)

[Suggested Code] HONGIKINGAN CMS Deployment Script Example

#!/bin/bash
# [Suggested Code] HONGIKINGAN CMS Deployment Script Example

# Variable settings
TOMCAT_HOME="/opt/tomcat"
APP_NAME="humanframe"
WAR_FILE="${APP_NAME}.war"
BACKUP_DIR="${TOMCAT_HOME}/backup"
TIMESTAMP=$(date +%Y%m%d%H%M%S)

# Log function
log() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1"
}

# Start log
log "Deployment started"

# Check Tomcat status
if pgrep -f tomcat > /dev/null; then
    log "Stopping Tomcat..."
    ${TOMCAT_HOME}/bin/shutdown.sh
    
    # Wait for Tomcat shutdown
    count=0
    while pgrep -f tomcat > /dev/null; do
        sleep 1
        count=$((count+1))
        if [ $count -gt 60 ]; then
            log "Tomcat shutdown timeout. Attempting force kill..."
            pkill -9 -f tomcat
            break
        fi
    done
    log "Tomcat stopped"
else
    log "Tomcat is already stopped."
fi

# Create backup directory
if [ ! -d "${BACKUP_DIR}" ]; then
    log "Creating backup directory: ${BACKUP_DIR}"
    mkdir -p "${BACKUP_DIR}"
fi

# Backup existing application
if [ -d "${TOMCAT_HOME}/webapps/ROOT" ]; then
    log "Backing up existing application..."
    tar -czf "${BACKUP_DIR}/ROOT_${TIMESTAMP}.tar.gz" -C "${TOMCAT_HOME}/webapps" ROOT
    log "Backup completed: ${BACKUP_DIR}/ROOT_${TIMESTAMP}.tar.gz"
fi

# Remove existing application
log "Removing existing application..."
rm -rf "${TOMCAT_HOME}/webapps/ROOT"
rm -f "${TOMCAT_HOME}/webapps/ROOT.war"

# Deploy new application
log "Deploying new application..."
cp "${WAR_FILE}" "${TOMCAT_HOME}/webapps/ROOT.war"

# Start Tomcat
log "Starting Tomcat..."
${TOMCAT_HOME}/bin/startup.sh

# Verify deployment completion
log "Deployment completed. Checking logs..."
tail -f "${TOMCAT_HOME}/logs/catalina.out"

10.2.2 Automated Deployment

The deployment process can be automated using tools like Jenkins, Ansible, etc.

Jenkins Pipeline Example

pipeline {
    agent any
    
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
        
        stage('Build') {
            steps {
                sh 'mvn clean package -DskipTests'
            }
        }
        
        stage('Test') {
            steps {
                sh 'mvn test'
            }
        }
        
        stage('Deploy to Dev') {
            when {
                branch 'develop'
            }
            steps {
                sh 'ansible-playbook deploy-dev.yml'
            }
        }
        
        stage('Deploy to Test') {
            when {
                branch 'release/*'
            }
            steps {
                sh 'ansible-playbook deploy-test.yml'
            }
        }
        
        stage('Deploy to Production') {
            when {
                branch 'master'
            }
            steps {
                input 'Deploy to production?'
                sh 'ansible-playbook deploy-prod.yml'
            }
        }
    }
    
    post {
        always {
            junit '**/target/surefire-reports/*.xml'
        }
        success {
            echo 'Deployment successful!'
        }
        failure {
            echo 'Deployment failed!'
            mail to: 'team@example.com',
                 subject: "Failed Pipeline: ${currentBuild.fullDisplayName}",
                 body: "Something is wrong with ${env.BUILD_URL}"
        }
    }
}

10.2.3 Zero-Downtime Deployment

A method to deploy applications without service interruption.

Blue-Green Deployment

🔵 Prepare Two Environments

Blue environment: Currently operating environment
Green environment: Environment to deploy new version

🟢 Deploy to Green Environment

Deploy new version to green environment
Perform testing in green environment

🔄 Switch Traffic

Change load balancer settings to switch traffic to green environment

🔵 Update Blue Environment

Update blue environment to new version
Maintain as standby environment for next deployment

Canary Deployment

🐤 Partial New Version Deployment

Deploy new version to only some servers

📊 Partial Traffic Switch

Switch some traffic (e.g., 5%) to new version

🔍 Monitoring & Verification

Monitor performance and stability of new version
Gradually increase traffic ratio if no issues

✅ Complete Switch

Switch all traffic to new version

10.3 Configuration Items to Check During Deployment

There are configuration items that must be checked when deploying HONGIKINGAN CMS. If these configurations are not properly set up, the system may not function correctly.

10.3.1 context-properties.xml Configuration

Each configuration item within the profile (dev for development, prd for production) suitable for the server purpose must be modified to match the actual server.

Required Configuration (Change) Items

GLOBAL_SITE_DOMAIN: Site domain
WEB_DIR: Web application directory path
THEME_PATH: Theme directory path

Optional Configuration Items

DAUM_API_KEY: When using Daum Map, Address API options
NAVER_API_KEY: When using Naver Map API options
GOOGLE_API_KEY: When using Google Map API options

context-properties.xml Example

<beans profile="dev">
    <bean id="propertiesService" class="org.egovframe.rte.fdl.property.impl.EgovPropertyServiceImpl">
        <property name="properties">
            <props>
                <prop key="GLOBAL_SITE_DOMAIN">http://dev.example.com</prop>
                <prop key="WEB_DIR">/home/dev/humanframe</prop>
                <prop key="THEME_PATH">/home/dev/humanframe/theme</prop>
            </props>
        </property>
    </bean>
</beans>

<beans profile="prd">
    <bean id="propertiesService" class="org.egovframe.rte.fdl.property.impl.EgovPropertyServiceImpl">
        <property name="properties">
            <props>
                <prop key="GLOBAL_SITE_DOMAIN">http://www.example.com</prop>
                <prop key="WEB_DIR">/home/prod/humanframe</prop>
                <prop key="THEME_PATH">/home/prod/humanframe/theme</prop>
            </props>
        </property>
    </bean>
</beans>

10.3.2 DBMS JNDI Configuration

The default JNDI name used within the CMS is "cmsdb". Related settings can be checked and changed in context-datasource.xml.

context.xml Configuration Example When Using Tomcat

<Resource name="jdbc/cmsdb" 
          auth="Container" 
          type="javax.sql.DataSource"
          maxTotal="100" 
          maxIdle="30" 
          maxWaitMillis="10000"
          username="cmsuser" 
          password="cmspassword" 
          driverClassName="com.mysql.cj.jdbc.Driver"
          url="jdbc:mysql://localhost:3306/cmsdb?serverTimezone=UTC"/>

ℹ️

Other WAS Server Configuration

Configuration must be added according to the JNDI configuration method for each server product.

10.3.3 Spring Profile Configuration

Spring Profile must be applied when starting the WAS server.

VM arguments Configuration

-Dspring.profiles.active=prd (production) or -Dspring.profiles.active=dev (development)

Configuration Example When Using Tomcat

Configuration inside /bin/catalina.sh file

# CMS PROFILE
JAVA_OPTS="$JAVA_OPTS -Dspring.profiles.active=prd"

10.3.4 Web Editor Configuration

When using editor-webeditorplus, you need to check the path configuration in the ImagePath.jsp file.

ImagePath.jsp Configuration Example

<%
String imagePhysicalPath = "";
String activeProfiles = System.getProperty("spring.profiles.active");
if("local".equalsIgnoreCase(activeProfiles)) {
    imagePhysicalPath = "D:\\H-CMS-2.2\\workspace\\humanframe";
} else if("dev".equalsIgnoreCase(activeProfiles)) {
    imagePhysicalPath = "/home/dev/humanframe";
} else {
    imagePhysicalPath = "/home/prod/humanframe";
}
%>

⚠️

Important Note

You must verify that the imagePhysicalPath variable matches the actual server's absolute path and modify it if necessary.

10.4 Environment-Specific Configuration Management

HONGIKINGAN CMS can apply different configurations for each environment using Spring profiles.

10.4.1 Profile Configuration

Profile Definition (context-properties.xml)

<beans profile="local">
    <!-- Local environment configuration -->
</beans>

<beans profile="dev">
    <!-- Development environment configuration -->
</beans>

<beans profile="test">
    <!-- Test environment configuration -->
</beans>

<beans profile="prd">
    <!-- Production environment configuration -->
</beans>

Profile Activation Methods

☕ Activate with JVM Options

-Dspring.profiles.active=dev

🌐 Activate in web.xml

<context-param>
    <param-name>spring.profiles.active</param-name>
    <param-value>dev</param-value>
</context-param>

🔧 Activate with Environment Variables

export SPRING_PROFILES_ACTIVE=dev

10.4.2 Environment-Specific Configuration Files

DataSource Configuration

context-datasource.xml

<beans profile="local">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/localdb" />
</beans>

<beans profile="dev">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/devdb" />
</beans>

<beans profile="test">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/testdb" />
</beans>

<beans profile="prd">
    <jee:jndi-lookup id="dataSource" jndi-name="java:comp/env/jdbc/proddb" />
</beans>

Properties Configuration

Environment-Specific Properties Configuration Example

<beans profile="local">
    <bean id="propertiesService" class="org.egovframe.rte.fdl.property.impl.EgovPropertyServiceImpl">
        <property name="properties">
            <props>
                <prop key="WEB_DIR">C:/dev/workspace/humanframe</prop>
                <prop key="FILE_UPLOAD_DIR">/data</prop>
                <prop key="LOG_PATH">/logs</prop>
            </props>
        </property>
    </bean>
</beans>

<beans profile="prd">
    <bean id="propertiesService" class="org.egovframe.rte.fdl.property.impl.EgovPropertyServiceImpl">
        <property name="properties">
            <props>
                <prop key="WEB_DIR">/home/prod/humanframe</prop>
                <prop key="FILE_UPLOAD_DIR">/data</prop>
                <prop key="LOG_PATH">/logs</prop>
            </props>
        </property>
    </bean>
</beans>

10.5 Backup & Recovery

A backup and recovery strategy must be established to quickly recover in case of system failure.

10.5.1 Database Backup

MySQL Backup

# Full database backup
mysqldump -u username -p --all-databases > backup_$(date +%Y%m%d).sql

# Specific database backup
mysqldump -u username -p humanframe > humanframe_$(date +%Y%m%d).sql

# Compressed backup
mysqldump -u username -p humanframe | gzip > humanframe_$(date +%Y%m%d).sql.gz

Oracle Backup

# Using exp utility
exp username/password@sid file=backup_$(date +%Y%m%d).dmp full=y

# Using expdp utility
expdp username/password@sid directory=DATA_PUMP_DIR dumpfile=backup_$(date +%Y%m%d).dmp full=y

10.5.2 File System Backup

Backup Using rsync

# Full application directory backup
rsync -avz --delete /home/humanframe/app/ /backup/humanframe/app/

# Upload files only backup
rsync -avz --delete /home/humanframe/data/ /backup/humanframe/data/

Backup Using tar

# Full application directory backup
tar -czf /backup/humanframe_$(date +%Y%m%d).tar.gz /home/humanframe/

# Incremental backup
tar -czf /backup/humanframe_$(date +%Y%m%d).tar.gz -g /backup/humanframe.snar /home/humanframe/

10.5.3 Automated Backup

Automatic Backup Using cron

/etc/cron.d/humanframe-backup

0 2 * * * root /home/humanframe/scripts/backup.sh

backup.sh Script

#!/bin/bash

# Variable settings
DATE=$(date +%Y%m%d)
BACKUP_DIR=/backup/humanframe
DB_USER=username
DB_PASS=password
DB_NAME=humanframe
APP_DIR=/home/humanframe

# Create directory
mkdir -p $BACKUP_DIR/$DATE

# Database backup
mysqldump -u $DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/$DATE/db_$DATE.sql.gz

# File system backup
tar -czf $BACKUP_DIR/$DATE/app_$DATE.tar.gz $APP_DIR/app
tar -czf $BACKUP_DIR/$DATE/data_$DATE.tar.gz $APP_DIR/data

# Delete old backups (30+ days)
find $BACKUP_DIR -type d -mtime +30 -exec rm -rf {} \;

# Log record
echo "Backup completed at $(date)" >> $BACKUP_DIR/backup.log

10.5.4 Recovery Procedures

Database Recovery

# MySQL recovery
mysql -u username -p humanframe < backup_20240101.sql

# Recovery from compressed file
gunzip -c backup_20240101.sql.gz | mysql -u username -p humanframe

File System Recovery

# Recovery from tar file
tar -xzf /backup/humanframe_20240101.tar.gz -C /

# Recovery using rsync
rsync -avz /backup/humanframe/app/ /home/humanframe/app/

10.6 Monitoring & Maintenance

Monitoring and maintenance plans must be established for stable system operation.

10.6.1 System Monitoring

Monitoring Targets

🖥️ Server Resources

CPU usage
Memory usage
Disk usage
Network traffic

🌐 Application

Response time
Error occurrence count
Concurrent users
Transaction throughput

🗄️ Database

Query execution time
Connection count
Table size
Index usage status

Monitoring Tools

📊Recommended Monitoring Tools

Prometheus + Grafana: Metric collection and visualization, alert configuration
ELK Stack: Log collection and analysis, anomaly detection
Pinpoint/Scouter: Application performance monitoring, transaction tracing

10.6.2 Log Management

Log Collection & Analysis

📥 Log Collection

Collect logs using Filebeat, Fluentd, etc.
Send to central log server

💾 Log Storage

Store logs in Elasticsearch
Set log retention period

📊 Log Analysis

Visualize and analyze logs using Kibana
Detect anomalies through log pattern analysis

Log Rotation

/etc/logrotate.d/humanframe

/home/humanframe/logs/*.log {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 0640 tomcat tomcat
    sharedscripts
    postrotate
        /bin/kill -USR1 $(cat /home/humanframe/tomcat/logs/catalina.pid 2>/dev/null) 2>/dev/null || true
    endscript
}

10.6.3 Regular Maintenance

Maintenance Items

🔄 Patches & Updates

Apply security patches
Library updates
Feature improvements

⚡ Performance Optimization

Database index optimization
Query tuning
Cache configuration adjustment

🧹 Data Cleanup

Delete unnecessary data
Clean up log files
Clean up temporary files

🔒 Security Inspection

Vulnerability scanning
Review access permissions
Review security settings

Maintenance Schedule

Frequency	Inspection Items
Daily Inspection	Check system status, check error logs, verify backup completion
Weekly Inspection	Analyze performance metrics, check disk space, review security logs
Monthly Inspection	Database optimization, clean up unnecessary data, apply security patches
Quarterly Inspection	Full system inspection, performance testing, disaster recovery testing

🎯

Deployment & Operations Key Points

Systematic Deployment Process: Step-by-step verification from development → test → production
Environment-Specific Configuration Management: Separate environment-specific configurations using Spring Profiles
Automated Backup: Regular database and file system backups
Continuous Monitoring: Monitor system status and performance metrics
Regular Maintenance: Security patches, performance optimization, data cleanup