<p>As a short term solution you can replay you last good build. Read the <a href="https://jenkins.io/doc/book/pipeline/development/#replay" rel="nofollow noreferrer">docs</a> for more information</p>

<p>Update: There is a <a href="https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36453" rel="nofollow noreferrer">bug </a>, so the proposed way will work only in multibranch pipeline. So as a short term solution you can convert your job to a multibranch pipeline and to use a replay when it’s needed </p>

<p>As a long term solution I would separate build and deployment job and store the build artifact in private npm registry. In that way you can always pick whatever version is needed to deploy</p>

CC BY-SA 4.0
2019-07-12T23:04:49.193Z
Hey Yuri - this is what I tried originally - but ran into this issue "When I do a "replay" however, it doesn't grab the actual commit the build ran on - it grabs the current commit in the repo. So it doesn't build the project from the commit it originally ran on - but the latest commit in the repo."
Justin H
CC BY-SA 4.0
2019-07-12T23:06:17.167Z
are you sure you are talking about replay and not rebuild? it's 2 different features
Yuri G.
CC BY-SA 4.0
2019-07-12T23:57:15.167Z
Looks like you’re right https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36453
Yuri G.
CC BY-SA 4.0
2019-07-13T00:01:20.973Z
Yeah, I was just testing this out again to make sure.  The proper way to do this though Yuri - I should have a build pipeline that stores artifacts over in Azure (say Azure blob)  - and then somehow store a reference to that build in the event I need to redeploy older code?  Any idea where a good tutorial on sometihng like that would be?  Thanks for the help.
Justin H
CC BY-SA 4.0
2019-07-13T00:16:48.353Z
Have a seen this https://wiki.jenkins.io/plugins/servlet/mobile?contentId=66848409#content/view/66848409
Yuri G.
CC BY-SA 4.0
2019-07-13T11:56:06.717Z
I like this idea and using "tags" to deploy a specific artefact - separating CI and CD. A solution could be to tag git after passing CI. The multi-branch plugin can then detect there is a new tag and trigger a new set of stages.
Robert
CC BY-SA 4.0
2019-07-12T22:58:51.073Z
2019-07-12T23:59:31.080Z
2019-07-12T23:59:31.080Z
Yuri G.
<p>I am pretty new to jenkins and trying to figure out the best way to accomplish rollbacks.  Currently this is my pipeline:</p>

<ol>
<li>Obtain a webhook from beanstalk (git versioning)</li>
<li>Build the project</li>
<li>Obtain the build artifact and deploy to Azure</li>
</ol>

<p>This is working great - the last thing I would like to solve is being able to rollback the project to a specific build. </p>

<p>When I do a "replay" however, it doesn't grab the actual commit the build ran on - it grabs the current commit in the repo.  So it doesn't build the project from the commit it originally ran on - but the latest commit in the repo. </p>

<pre><code>pipeline {
agent any
stages {

    stage('Install Dependenciess') {
        steps {
            bat'npm install'
        }
    }

    stage('Build the Project') {
        steps {
            bat'npm run build'
        }
    }

    stage('Deploy to Azure Prod') {
        when {
            environment name: 'REPOSITORY_BRANCH', value: 'master'
            beforeAgent true
        }
        steps {

            timeout(time:5, unit: 'DAYS') {
                input message: 'Approve Deployment?'
            }

            azureWebAppPublish azureCredentialsId: env.AZURE_CRED_ID,
            resourceGroup: env.RES_GROUP, 
            appName: env.WEB_APP, 
            filePath: "**/*.*",
            sourceDirectory: "build"
        }
    }

    stage('Deploy to Azure Development') {
        when {
            environment name: 'REPOSITORY_BRANCH', value: 'development'
            beforeAgent true
        }
        steps {

            azureWebAppPublish azureCredentialsId: env.AZURE_CRED_ID,
            resourceGroup: env.RES_GROUP, 
            appName: env.WEB_APP, 
            filePath: "**/*.*",
            sourceDirectory: "build"
        }
    }

}

post {
    always {
        archiveArtifacts artifacts: "build/**/*.*", onlyIfSuccessful: true
        cleanWs()
    }

    success {
        mail bcc: '', body: "&lt;b&gt;Example&lt;/b&gt;&lt;br&gt;Project: ${env.JOB_NAME} &lt;br&gt;Build Number: ${env.BUILD_NUMBER} &lt;br&gt; URL de build: ${env.BUILD_URL}", cc: '', charset: 'UTF-8', from: '', mimeType: 'text/html', replyTo: '', subject: "ERROR CI: Project name -&gt; ${env.JOB_NAME}", to: "";
    }

}
</code></pre>

<p>}</p>

CC BY-SA 4.0
2019-07-12T22:02:03.510Z
do you store the built artifacts somewhere?
Yuri G.
CC BY-SA 4.0
2019-07-12T22:13:02.043Z
@YuriG. I keep the last 10 deployments.  So if I open an old build I can see the build files for that particular run.

I looked into storing builds over in Azure Blob - but if I have to rollback I am unsure how I would set up a process to go grab those old artifacts to re-deploy to Azure.  Bear in mind - our company will have dozens of projects running on this same build process.
Justin H
CC BY-SA 4.0
2019-07-12T22:28:49.200Z
If I understand correctly, right now, the same Jenkins job builds the project and deploys it. Am I right?
Yuri G.
CC BY-SA 4.0
2019-07-12T22:43:16.403Z
@YuriG. - Yep that is correct.  I will post my build steps above
Justin H
<azure>
Jenkins Rerun Old Build with Specific Commit
Justin H
# Jenkins Rerun Old Build with Specific Commit

(Asked by: username_0 on 2019-07-12)

I am pretty new to jenkins and trying to figure out the best way to accomplish rollbacks.  Currently this is my pipeline:

Obtain a webhook from beanstalk (git versioning)
Build the project
Obtain the build artifact and deploy to Azure

This is working great - the last thing I would like to solve is being able to rollback the project to a specific build. 
When I do a "replay" however, it doesn't grab the actual commit the build ran on - it grabs the current commit in the repo.  So it doesn't build the project from the commit it originally ran on - but the latest commit in the repo. 
pipeline {
agent any
stages {

    stage('Install Dependenciess') {
        steps {
            bat'npm install'
        }
    }

    stage('Build the Project') {
        steps {
            bat'npm run build'
        }
    }

    stage('Deploy to Azure Prod') {
        when {
            environment name: 'REPOSITORY_BRANCH', value: 'master'
            beforeAgent true
        }
        steps {

            timeout(time:5, unit: 'DAYS') {
                input message: 'Approve Deployment?'
            }

            azureWebAppPublish azureCredentialsId: env.AZURE_CRED_ID,
            resourceGroup: env.RES_GROUP, 
            appName: env.WEB_APP, 
            filePath: "**/*.*",
            sourceDirectory: "build"
        }
    }

    stage('Deploy to Azure Development') {
        when {
            environment name: 'REPOSITORY_BRANCH', value: 'development'
            beforeAgent true
        }
        steps {

            azureWebAppPublish azureCredentialsId: env.AZURE_CRED_ID,
            resourceGroup: env.RES_GROUP, 
            appName: env.WEB_APP, 
            filePath: "**/*.*",
            sourceDirectory: "build"
        }
    }

}

post {
    always {
        archiveArtifacts artifacts: "build/**/*.*", onlyIfSuccessful: true
        cleanWs()
    }

    success {
        mail bcc: '', body: "ExampleProject: ${env.JOB_NAME} Build Number: ${env.BUILD_NUMBER}  URL de build: ${env.BUILD_URL}", cc: '', charset: 'UTF-8', from: '', mimeType: 'text/html', replyTo: '', subject: "ERROR CI: Project name -> ${env.JOB_NAME}", to: "";
    }

}

}

**Tags:** azure

> **Comments:**
> **username_1**: do you store the built artifacts somewhere?  
> **username_0**: @YuriG. I keep the last 10 deployments.  So if I open an old build I can see the build files for that particular run.  I looked into storing builds over in Azure Blob - but if I have to rollback I am unsure how I would set up a process to go grab those old artifacts to re-deploy to Azure.  Bear in mind - our company will have dozens of projects running on this same build process.  
> **username_1**: If I understand correctly, right now, the same Jenkins job builds the project and deploys it. Am I right?  
> **username_0**: @YuriG. - Yep that is correct.  I will post my build steps above  

---

## 1 answers

### Answer by username_1 on 2019-07-12. Score: 1 | Accepted answer

As a short term solution you can replay you last good build. Read the [docs](https://jenkins.io/doc/book/pipeline/development/#replay) for more information

Update: There is a [bug](https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36453) , so the proposed way will work only in multibranch pipeline. So as a short term solution you can convert your job to a multibranch pipeline and to use a replay when it’s needed

As a long term solution I would separate build and deployment job and store the build artifact in private npm registry. In that way you can always pick whatever version is needed to deploy

> **Comments:**
> **username_0**: Hey Yuri - this is what I tried originally - but ran into this issue "When I do a "replay" however, it doesn't grab the actual commit the build ran on - it grabs the current commit in the repo. So it doesn't build the project from the commit it originally ran on - but the latest commit in the repo."  
> **username_1**: are you sure you are talking about replay and not rebuild? it's 2 different features  
> **username_1**: Looks like you’re right https://issues.jenkins-ci.org/plugins/servlet/mobile#issue/JENKINS-36453  
> **username_0**: Yeah, I was just testing this out again to make sure.  The proper way to do this though Yuri - I should have a build pipeline that stores artifacts over in Azure (say Azure blob)  - and then somehow store a reference to that build in the event I need to redeploy older code?  Any idea where a good tutorial on sometihng like that would be?  Thanks for the help.  
> **username_1**: Have a seen this https://wiki.jenkins.io/plugins/servlet/mobile?contentId=66848409#content/view/66848409  
> **username_2**: I like this idea and using "tags" to deploy a specific artefact - separating CI and CD. A solution could be to tag git after passing CI. The multi-branch plugin can then detect there is a new tag and trigger a new set of stages.  

---

