Wednesday, June 1, 2022

Azure DevOps vs Jenkins

 

Azure DevOps vs Jenkins

  • Group Tasks – Azure allows you to perform a sequence of tasks, already defined in a pipeline, into a single task, whereas Jenkins is generally done by a single user which leads to tracking and accountability problems.
  • YAML Interface – With YAML in Azure Pipelines, you can configure CI/CD pipeline as code, whereas Jenkins doesn’t have a YAML interface.
  • Platform, language, and cloud – In Azure Pipelines, you can deploy various applications including Node.js, android, iOS, java, python, and many more and then deploy to either on-premise, AWS, Azure, or GCP. With regards to Jenkins, you get scripted pipelines that must be programmed in Groovy.
  • Analytics in Azure Pipelines is provided at the end with two parameters – rate and duration of the run. Jenkins doesn’t provide any analytics.
  • Plugins and Tasks – The built-in plugins and extensions can be downloaded from Azure DevOps marketplace. Jenkins has a wide range of plugins to choose from.
  • Integration of Azure Pipelines with Microsoft is easy, but requires configuration changes to integrate with non-Microsoft products. Jenkins, on the other hand, can easily be modified and extended.
  • Easy Support – Since Jenkins is open source, there is a huge support from the agile teams.

Who wins the battle?

The battle boils down to the team or the project you work on. While Jenkins is more flexible to create and deploy complex workflows, Azure DevOps is faster to adapt. In most cases, organizations use both the tools and in such cases, Azure Pipelines supports integration with Jenkins.



Concerns with Jenkins: 

  • 12
    Workarounds needed for basic requirements
  • 9
    Groovy with cumbersome syntax
  • 7
    Plugins compatibility issues
  • 6
    Lack of support
  • 6
    Limited abilities with declarative pipelines
  • 4
    No YAML syntax
  • 3
    Too tied to plugins versions


  • Sample Jenkins File 

  • pipeline {
  •     agent none
  •     stages {
  •         stage('Build') {
  •             steps {
  •                 sh 'npm install'
  •                 sh 'npm run build'
  •             }
  •         }
  •         stage('Test') {
  •             steps {
  •                 sh 'npm test'
  •             }
  •         }
  •     }
  • }


  • Azure-pipeline.yaml
  • jobs:
  • - job: Build
  •   steps:
  •   - script: npm install
  •   - script: npm run build
  • - job: Test
  •   steps:
  •   - script: npm test


  • If we containerized our applications.
  • Jenkinsfile
  • pipeline {
  •     agent none
  •     stages {
  •         stage('Build') {
  •             agent {
  •                 docker {
  •                     image 'ubuntu:trusty'
  •                     args '-v $HOME:/build -w /build'
  •                 }
  •             }
  •             steps {
  •                 sh 'make'
  •             }
  •         }
  •         stage('Test') {
  •             agent {
  •                 docker {
  •                     image 'ubuntu:xenial'
  •                     args '-v $HOME:/build -w /build'
  •                 }
  •             }
  •             steps {
  •                 sh 'make test'
  •             }
  •         }
  •     }
  • }

  • Azure-pipeline.yaml

  • resources:
  •   containers:
  •   - container: trusty
  •     image: ubuntu:trusty
  •   - container: xenial
  •     image: ubuntu:xenial

  • jobs:
  • - job: build
  •   container: trusty
  •   steps:
  •   - script: make
  • - job: test
  •   dependsOn: build
  •   container: xenial
  •   steps:
  •   - script: make test


  • After completion Jenkinsfile

  • post {
  •     always {
  •         echo "The build has finished"
  •     }
  •     success {
  •         echo "The build succeeded"
  •     }
  •     failure {
  •         echo "The build failed"
  •     }
  • }
  • Azure-pipeline.yaml

  • jobs: - job: always steps: - script: echo "The build has finished" condition: always() - job: success steps: - script: echo "The build succeeded" condition: succeeded() - job: failed steps: - script: echo "The build failed" condition: failed()


  • https://blog.opstree.com/2021/04/13/jenkins-vs-azure-devops/

  • Jenkins CI Pipeline for SpringBoot Application : Pipeline Script VS Pipeline Script from SCM

     Here we will create CI and CD Pipelines to build and deploy application using Jenkins pipelines.

    We can create in two was 

    1. Pipeline Script 

    2. Pipeline Script from SCM

    Saturday, May 28, 2022

    Docker : Docker, DockerCompose and DockerRun and params

    Docker : Plugins comparison : palantir VS bmuschko

     https://plugins.gradle.org/search?term=com.palantir.docker


    https://palantir.github.io/

    https://tomgregory.com/bmuschko-docker-gradle-plugin-review/


    https://tomgregory.com/automating-docker-builds-with-gradle/



    Thursday, May 26, 2022

    RestControllerAdvice VS ControllerAdvice VS ExceptionHandler - Interrupt the StackTraces, LOG.ERROR

     @ExceptionHandler can be used at the local level or at the global level. Local level would mean using this annotation within the controller itself to handle the exceptions within that controller only. All error thrown by that controller would be caught by that @ExceptionHandler. But this would mean that if there is a similar exception in a different controller you would have to rewrite the corresponding code again in that controller again locally.

    In order to prevent repeating this style of exception handling per controller we can write the @ExceptionHanlder at the global level with the help of another annotation called @ControllerAdvice.

    @ControllerAdvice is not specific to the exception handling , its also used for handling property, validation or formatter bindings at the global level. @ControllerAdvice in the context of exception handling is just another way of doing exception handling at a global level using @Exceptionhandler annotation.

    Now coming to the HandlerExceptionResolver - this is an interface at a more lower level. Spring provides 2 implementations of this:

    • ResponseStatusExceptionResolver :This supports the support the @ResponseStatus annotation
    • ExceptionHandlerExceptionResolver : This supports the @ExceptionHandler annotation

    Example : So when you want to handle exceptions and choose an exception handling strategy you will need to think of choosing between using a local or global exception handling via the annotations. How you need to provide the HTTP status codes, how to wrap it in the @Response entity etc, how you want to redirect to handler pages , carry the data via flash attributes or get params etc etc. Or maybe skip the annotations and use the SimpleMappingExceptionResolver and start mapping the specific exceptions to the error handler page urls

    Here we are not be considering the lower level underlying HandlerExceptionResolver at this stage since we are dealing with its implementation at a higher level and building the strategy based on these options.

    With the above context to answer your query - @ControllerAdvice was not introduced for exception handling, it's a mechanism you can leverage to handle exceptions globally using the @ExceptionHandler. HandlerExceptionResolver is an interface whose implementation helps support the @ResponseStatus and the @Exceptionhandler annotations. Unless you want to handle the exceptions related to the MVC system because the Spring framework does not provide any proper exception handling. So if you need to hand;e issues related to incorrect @Requestmapping etc which would not be caught by a controller as it would not even reach it in the 1st place then an implementation of the HandlerExceptionResolver would be useful

    Order Service API - Simple Microservice for Order Creation

    Git Repo:

    https://github.com/balajimathu/beer-order-service





    Create Below APIs using Spring Webflux.

     1. Order Service -  will invoke below APIs use  spring-boot-starter-validation

    2. Inventory Service -  search and confirm availability, if not available Order Service will return message.

    3. Price Service - Search and get latest price, Store actual prices in DB,  implement Spring Data to apply seasonal offers, configurable

    4. Shipment Service - On successful creation Send mail.  @Email - -Validation

    5. Payment Service - Insert data in DB and return an transaction id. 

    6. Implement @ControllerAdvice - Reactive


    Implement CommandLineRunner to check the availability of DependencyAPIs on startup..

    Database:

    Postgres


    Platform:

    Create Docker Images for REST APIs and Postgres DB

    Run Jenkins on AWS EC2

    CI and CD Pipelines

    Deploy all these in Containers, separately, 

    Authentication - NO Auth as of now.