Automating the Build and Deploy Pipeline

Dev-server deployments were entirely manual — build, transfer, restart, all done by hand. A single deploy took 15–20 minutes, during which other developers were stuck waiting, and there was no record anywhere of who deployed what and when. With frequent deploys, a mistyped command or a wrong-environment slip would creep in from time to time, and each one added a rollback-and-redeploy overhead on top.

• 15–20 min per deploy on average

  Build, transfer, and restart all run manually in sequence

• No way to trace deploy history

  No record of who deployed what and when

• Blocking wait time

  Other work would stall while a deploy was in progress

• Human errors during manual work

  Typos or wrong-environment mix-ups occasionally caused incidents

Using a Jenkins Declarative Pipeline, I defined the whole build-and-deploy procedure in a single Jenkinsfile. A GitLab Webhook detects pushes to a specific branch, and the Checkout → Build → Deploy stages run in sequence.

1. 01

   Run Jenkins in a Docker container

   To avoid messing up the host environment, I ran Jenkins inside a Docker container. Jobs, plugins, and credentials were split out to volumes, so the configuration survives restarts intact.

2. 02

   Connect the GitLab Webhook

   Push events from the GitLab repository are forwarded to Jenkins, and a regexpFilterExpression filters them so the build only runs for pushes to the devtest branch.

3. 03

   Write the Jenkinsfile

   I split the pipeline into Checkout → Build → Deploy stages, so if something fails it is immediately obvious which stage stopped. Deploy ships the WAR file over SSH and then runs the server-side deploy.sh to handle the WAS restart — all in one go.

   Jenkinsfile

   groovy

   // Jenkins Declarative Pipeline - GitLab Webhook 연동 자동 배포
   pipeline {
       agent any
    
       triggers {
           GenericTrigger(
               genericVariables: [
                   [key: 'BRANCH_NAME', value: '$.ref'],
                   [key: 'EVENT_TYPE',  value: '$.event_name']
               ],
               regexpFilterExpression: '^refs/heads/devtest push$'
           )
       }
    
       stages {
           stage('Checkout') {
               steps {
                   git branch: 'devtest',
                       credentialsId: 'gitlab-ssh-key',
                       url: 'ssh://git@server/gitlab/goad.git'
               }
           }
    
           stage('Build') {
               steps {
                   sh 'mvn clean package -P staging'
               }
           }
    
           stage('Deploy') {
               steps {
                   sshPublisher(publishers: [
                       sshPublisherDesc(
                           configName: 'staging-server',
                           transfers: [sshTransfer(
                               sourceFiles: 'target/issga.war',
                               execCommand: '/home/deploy/deploy.sh'
                           )]
                       )
                   ])
               }
           }
       }
   }

4. 04

   Surface build status on GitLab commits

   Build results are reported back as GitLab commit statuses, so when you look at a commit in GitLab you can immediately see whether the build succeeded, failed, or is still running.

• Deploy time: 20 min → 4 min

  Work that used to take 15–20 minutes manually dropped to around 4 minutes with the automated pipeline.

• Manual mistakes disappeared

  The kinds of errors that came from manual steps — command typos, wrong-environment mix-ups — are now virtually gone.

• No more blocking wait time

  Once a push goes out, developers can move straight on to the next task while the pipeline runs.

• Pipeline beat Freestyle

  I first tried a Freestyle Job, but Pipeline turned out to be far better for traceability, reuse, and extensibility. It really drove home why capturing the procedure as code matters.