Operations 14 min read

Automating Deployment for SMEs: A Step‑by‑Step Shell Guide

This article outlines a practical, resource‑conscious approach for small and medium‑size enterprises to design and implement an automated deployment pipeline using shell scripts, covering goal setting, process design, key deployment steps, tips, rollback procedures, and frequently asked questions.

Efficient Ops
Efficient Ops
Efficient Ops
Automating Deployment for SMEs: A Step‑by‑Step Shell Guide

Unified Understanding

In IT management there are three core elements, abbreviated as PPT: People (personnel/organization), Process, and Tech/Tool.

Designing an automated deployment system is not just about installing tools or writing scripts; it must align with the organization’s structure, processes, and technology.

Determine Goals

For SMEs the deployment environment typically involves rapid updates, limited testing, and clusters of up to about 100 servers. The main objectives are:

One‑click release

Second‑level rollback

Process Design

The focus is on the production environment deployment workflow, assuming code is ready in a Git or SVN repository.

Typical steps include:

Acquire code (svn/git, specific tag/commit, or latest)

Compile (optional for Java, not needed for Python/PHP)

Match environment configuration files (manage sensitive configs separately)

Package (e.g., tar czf)

Copy package to target servers (using SCP, verify with MD5)

Remove node from load‑balancer pool before deployment

Extract package on target

Create symlink to the new version

Copy differential files (e.g., cron jobs)

Restart web service if needed (e.g., Tomcat)

Run automated tests (curl or custom API)

Add node back to the pool

Repeat for next node

Process Analysis

1. Get Code

Perform code checkout on a dedicated deployment server, not on each web server.

2. Compile

Java projects may need Ant or Maven; other languages skip this step.

prod_web_xxxxx_2015-09-09-10:10

3. Match Environment Config Files

Separate version‑controlled config repositories for sensitive settings; copy them into the code directory during deployment.

4. Package

Use tar czf to create an archive.

5. Copy Package

Transfer with SCP and verify integrity via MD5 checksum.

6. Remove Node from Cluster

Use socat with HAProxy socket to disable the server before deployment:

echo "disable server www_example_com/web-node1" | socat /usr/local/haproxy/haproxy.sock stdio

echo "enable server www_example_com/web-node1" | socat /usr/local/haproxy/haproxy.sock stdio

7. Extract Package

Unpack on the target server using any management tool (SaltStack, SSH, etc.).

8. Create Symlink

Link the web root to the new version directory, enabling instant rollback by switching the symlink.

webroot -> /data/prod_web_xxxxx_2015-09-09-10-10/

9. Copy Differential Files

Deploy environment‑specific files such as crontab.xml for scheduled tasks.

10. Restart Web Service

Restart services like Tomcat if required, and clear caches.

11. Automated Testing

Invoke health‑check APIs or use curl to verify responses before proceeding.

12. Add Node Back to Cluster

Re‑enable the server in HAProxy via the same socat command.

13. Continue with Next Node

Loop the process for each server in the cluster.

Deployment Tips

Group Deployment: Split servers into groups (e.g., group1, group2, group3) to parallelize restarts and testing, reducing overall downtime.

Logging: Implement detailed logging in scripts to track progress and errors.

Deploying server redundancy and version‑controlled scripts are essential for reliability.

Rollback Process

Standard rollback steps:

List available rollback versions (e.g., ls -l)

Remove node from cluster

Delete old symlink and create a new one pointing to the previous version

Optional restart

Run automated tests

Add node back to cluster

Proceed to next node

For urgent rollbacks, directly switch to the last known good version without listing, ensuring the previous version is recorded.

FAQ

Q: Is there a complete deployment diagram?

A: Yes, the article includes several diagrams illustrating the workflow.

Q: Do you use Jenkins for automation?

A: Jenkins is used in the testing environment, but production relies on a SaltStack‑based job platform.

Q: How to ensure consistency across servers?

A: Use separate config repositories, version control, and load‑balancer strategies like IP hash or source‑based routing.

Q: Can we adopt this process for our production line?

A: Absolutely; shell script templates will be provided.

Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

AutomationDeploymentConfigurationShellrollback
Efficient Ops
Written by

Efficient Ops

This public account is maintained by Xiaotianguo and friends, regularly publishing widely-read original technical articles. We focus on operations transformation and accompany you throughout your operations career, growing together happily.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.