Jenkins Front‑End Deployment: Pipeline vs Freestyle and Core Scripts

Jenkins Front‑End Deployment Overview

Jenkins is an open‑source automation server that can help automate various tasks, including building, testing, and deploying software.

Pipeline vs. Freestyle Projects

Pipeline projects, introduced in Jenkins 2.0, use a Jenkinsfile written in Groovy DSL to define the entire build flow, supporting multiple stages, parallel execution, and advanced features. They integrate easily with source‑code management systems to enable continuous integration (CI) and continuous delivery (CD).

Freestyle projects are the classic Jenkins job type configured through the web UI. They allow manual addition of build steps, plugins, and parameters, making them quick to set up for simple tasks but less flexible for complex pipelines.

The main differences are:

Definition method: Pipeline uses a Jenkinsfile ; Freestyle uses the UI.

Flexibility and extensibility: Pipeline supports complex workflows, parallelism, and templating.

Integration: Pipeline integrates more naturally with SCM for CI/CD.

Learning curve: Pipeline requires learning Groovy DSL, while Freestyle is more intuitive.

Pipeline tasks represent the future direction of Jenkins, offering more advanced automation capabilities, whereas Freestyle projects are suitable for quickly setting up simple build tasks.

Core Pipeline Scripts

3.1 Get Git Branch

3.1.1 Git Branch Plugin

The gitParameter plugin allows selection of a Git branch (e.g., develop or master ) during deployment.

3.1.2 Git Environment Variables

3.1.3 Retrieve Git Branch Code

A key code line (shown in the image) uses the Git plugin to obtain the selected branch.

3.2 Copy Dependency Packages

Since node_modules is not stored in Git, the dependencies are pre‑installed on a network‑connected Linux server using npm install , then compressed and manually copied to the Jenkins server’s passjava directory. During deployment, the compressed package is unpacked into the Jenkins workspace.

3.3 Build Code

The front‑end code is compiled with npm run build , and the resulting dist directory is compressed.

3.4 Backup Code

Existing front‑end projects on the web server are moved to a backup directory web‑bak .

3.5 Upload Code

The compressed build package is uploaded to the web server.

3.6 Update Code

The dist archive is unpacked and the front‑end projects (e.g., passjavabase , passjava-channel , project-contract ) are copied into the passjava-web-micro directory.

3.7 Clean Up Code

Old backup directories on the web server are removed. The following command finds sub‑directories under /nfs-data/passjava/web-bak/ that have not been modified for more than 7 days and deletes them:

-mindepth 1    # start searching from sub‑directories only
-maxdepth 1    # limit to the first level of sub‑directories
-type d        # match directories only
-mtime +7      # modified more than 7 days ago
-print          # output the paths
-exec rm -rf {} +   # delete each found directory

The complete script is shown in the following image:

3.8 Email Notification

For details on email notifications, refer to the author’s previous article "Continuous Integration: Jenkins Pipeline Email Notification".

Conclusion

Using Jenkins Pipeline for front‑end automated deployment enables teams to manage and release front‑end applications more efficiently, reducing manual errors and improving overall development and deployment speed.

The article combines diagrams and code to illustrate the deployment steps; future improvements could include selective deployment of individual front‑end modules.