DevOps Classroomnotes 14/May/2022

Build Triggers

  • When the project should be built?
  • Generally organizations follow two types of builds
    • Day Builds:
      • Builds done during active development
      • Two options:
        • Build for every change pushed by a developer
        • Build for every one hour or two hours in active working timings
      • We are supposed to give feedback to developer on their commit i.e. if the build is passed, unit tests are passed and code coverage is ok, Static Code Analysis etc..
      • Generally day builds are on a different branch (develop, sprint-n-develop etc…)
    • Nightly Builds:
      • Consolidated build for all the work done by dev team(s) in one day
      • Build once in a day (Scheduled when no development )
      • Build should
        • Build the code
        • Unit tests
        • Static code analysis
        • Code Coverage
        • Run automated system tests and performance tests which require application to be deployed.
          • Tests might be developed using test automation tools like
            • Selenium
            • JMeter
            • Postman
            • Loadrunner
      • Nightbuilds on different branch (RELEASE_v1.0.0_SPRINTn)
  • Configuring Day Builds where a build is created for every commit:

    • Day build to be started when any developer pushes the changes to the branch
      Preview
      Preview
      Preview
    • Now make changes and push the changes to the configured branch
      Preview
      Preview
      Preview
      Preview
  • Configuring day build where we build periodically (every hour, every two hours) etc…
  • Lets work with some cron schedules
    1. Run every day at 11 AM, 7 PM
      Preview
    2. Run for every two hours
      Preview
    3. Run at 11:00 PM
      Preview
    4. Run at 01:00 AM on Saturday and Sunday
      Preview
  • Lets configure Jenkins day build to run every hour
    Preview
  • If you want to build every hour only when there are new commits then
    Preview
  • Refer Here for cron syntax and experimentation
  • Lets configure the night build to start at 11:00 PM IST on weekdays
    Preview
    Preview
    Preview

Jenkins Pipelines

  • Pipeline as a Code:
    • Build steps expressed in the format of code
    • Jenkins has developed a Domain Specific Language (DSL) based on Groovy Language.
    • Lot of other CI/CD tools are also based on pipelines as a Code
      • Azure DevOps – YAML
      • GitLab – YAML
      • GitHub Actions – YAML
  • Advantages of Pipeline as a code:
    • This pipeline will be part of source code repo, i.e. version will be maintained
    • Branch wise build changes can be handled easily
  • Jenkinsfile:
    • This is the file in which we define pipelines or build steps
    • Earlier the name was supposed to be Jenkinsfile, now it can be any file
  • Pipeline Types:
    • Scripted Pipeline:
      • It is procedure oriented and we can directly use groovy code over here
    • Declarative Pipeline
      • This is declarative and easy to work with
  • Lets create a first pipeline for daybuild of gameoflife
    Preview
    Preview
    Preview
  • Syntax for scripted pipeline
node('<LABEL>') {
    stage('<Build-stage-1') {
        // build steps
    }
    ..
    ..
    stage('<Build-stage-n') {

    }
}

Preview
* Now select Pipeline from SCM in the Pipeline section
Preview
Preview
* Now build the project
Preview

Scripted Pipelines

  • Advantages:
    • Generally few sections and less specifications needed
    • Capability to use more procedural code
    • More like create a program
    • More flexibility to do custom operation
  • DisadvantageS:
    • More programming required in general
    • Syntax checking limited to Groovy language and environment
    • Looks different from traditional Jenkins model
    • More complex
  • Structure:
    Preview
  • Example:
node('JDK8') {
    stage('SourceCode') {
        // get the code from git repo on the branch sprint1_develop
        git branch: 'sprint1_develop', url: 'https://github.com/KhajasCICDSamples/game-of-life.git'
    }

    stage('Build the code') {
        sh 'mvn clean package'
    }

    stage('Archiving and Test Results') {
        junit '**/surefire-reports/*.xml'
        archiveArtifacts artifacts: '**/*.war', followSymlinks: false
    }

}

Declarative Pipelines

  • Advantages:
    • More structure
    • More capability to declare what is needed
    • Can be generate from Blue Ocean graphical interface
    • Contains sections that map to tradional jenkins
    • Better syntax checking and error identification
  • Disadvantage:
    • Still evolving
    • Iterative logic is less supported
  • Structure:
    Preview
  • Pipeline Steps Reference Refer Here
  • Pipeline Syntax reference Refer Here
  • Lets add a daybuild trigger to build the jenkins job whenever there is a new commit by polling scm
  • Triggers section Refer Here
  • JenkinsFile:
pipeline {
    agent { label 'JDK8' }
    triggers { pollSCM('* * * * *') }
    stages {
        stage('SourceCode') {
            steps {
                git branch: 'sprint1_develop', url: 'https://github.com/KhajasCICDSamples/game-of-life.git'
            }
        }
        stage('Build') {
            steps {
                sh 'mvn clean package'
            }
        }
        stage('Archive and Test Results') {
            steps {
               junit '**/surefire-reports/*.xml'
               archiveArtifacts artifacts: '**/*.war', followSymlinks: false
            }
        }
    }
}

Preview
Preview
Preview
Preview
* Lets install Blue Ocean Interface via plugins
Preview
Preview
Preview
Preview

Open items

  • The free style projects creates xml files in Jenkins home directory and there is no version information. How to resolve these.
  • Static Source Code Analysis
  • Archiving the artifacts in the repository server
  • When the build fails we should be sending alerts, How to configure that?

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

About continuous learner

devops & cloud enthusiastic learner