Migrate WebApp from GitHub to Azure Cloud - Build Pipelines in Azure DevOps to migrate WebApp from GitHub to Azure Cloud | How to create Azure Classic pipeline in Azure DevOps?

We are going to migrate application from GitHub to Azure Cloud using Azure Classic Pipelines offered from Azure DevOps. 

Building pipelines in Azure DevOps is really easy, you can migrate your web application code from any where into Azure Cloud by using Azure pipelines.

 

 
Pre-requisites:

(If you already have a WebApp setup in Azure cloud, move to next step)

You need to create WebApp in Azure Cloud. WebApp is an App service (mostly Platform as a Service) provide by Azure Cloud to migrate any web applications.

Click here to learn how to create WebApp in Azure Portal.

Creating Azure Classic pipeline in Azure DevOps

1. Now go to your visual studio project page --> https://dev.azure.com/
Select the Project dashboard you already created.

Click on Pipelines, Builds.

2. Click on New pipeline and click on use the classic editor to create a pipeline without YAML

3. Select source repository as GitHub and click Authorize using OAuth

4. Now click on Authorize Azure Pipelines, enter GitHub password if it asks.

5. Now you should be able to select repositories by clicking ... dots

6. Since our application is Java stack, type Java and Choose Azure WebApp for Java

7. Click on pipeline name and re-name per your naming standard

8. Modify maven goal as clean install and also choose POM.xml by clicking on three dots ...

9. Leave the value as it is for Copy Files to staging folder

10. Leave the value as it is for Publish Artifact: Drop 
11. Click on Stop Azure WebApp step, Enter Azure WebApp details - where  you would like to deploy your app in Azure. Select Free trial subscription from the drop down.

12. Do the same in Deploy Azure WebApp & Start Azure WebApp steps.

Enable Webhooks in Pipeline

11. Click on Triggers and then enable check box for Continuous Integration

12. Now click on Save and Queue

13. If your configurations are correct, you should be able to see the build success and able to access in the Azure. Click on Pipelines and pipeline name

Now you will see that Azure DevOps would have started build.


14. Make sure build is success, it should have all green like below.

After successful build, you can check the output by accessing the URL, copying from WebApp configuration. Please append WAR file name after the url

http://myAzureWebAppUrl/MyWebApp

Clean-up Resources:

After successfully finishing the labs, make sure to delete all the resources created in Azure portal to avoid charges from Microsoft.

Select the resource group in Azure portal, delete the resource group. This will ensure that all the resources will be deleted under the resource group.

How to create Jenkinsfile - How to configure Declarative Pipeline - Jenkins Pipeline As code

Please find steps below for configuring pipeline as a code - Jenkinsfile.

Pre-requistes:

1. Project setup in Bitbucket/GitHub/GitLab
2. Jenkins and Tomcat (web container) set up.
3. Maven installed in Jenkins
4. Sonarqube setup and integrated with Jenkins
5. Nexus configured and integrated with Jenkins
6. Slack channel configured an integrated with Jenkins

Create Jenkinsfile (pipeline code) to your MyWebApp

Step 1

Go to GitHub and choose the Repo where you setup MyWebApp in Lab exercise # 2

Step 2
Click on create new file.


Step 3 - Enter Jenkinsfile as a file name
 

Step 4

Copy and paste the below code and make sure what ever is highlighted in red color needs to be changed per your settings.

That's it. Pipeline as a code - Jenkinsfile is setup in GitHub.

pipeline {
  agent any
 
  tools {
  maven 'Maven3'
  }
  stages {
    stage ('Build') {
      steps {
      sh 'mvn clean install -f MyWebApp/pom.xml'
      }
    }
    stage ('Code Quality') {
      steps {
        withSonarQubeEnv('SonarQube') {
        sh 'mvn -f MyWebApp/pom.xml sonar:sonar'
        }
      }
    }
    stage ('JaCoCo') {
      steps {
      jacoco()
      }
    }
    stage ('Nexus Upload') {
      steps {
      nexusArtifactUploader(
      nexusVersion: 'nexus3',
      protocol: 'http',
      nexusUrl: 'nexus_url:8081',
      groupId: 'myGroupId',
      version: '1.0-SNAPSHOT',
      repository: 'maven-snapshots',
      credentialsId: 'fc0f1694-3036-41fe-b3e3-4c5d96fcfd26',
      artifacts: [
      [artifactId: 'MyWebApp',
      classifier: '',
      file: 'MyWebApp/target/MyWebApp.war',
      type: 'war']
      ])
      }
    }
    stage ('DEV Deploy') {
      steps {
      echo "deploying to DEV Env "
      deploy adapters: [tomcat8(credentialsId: '268c42f6-f2f5-488f-b2aa-f2374d229b2e', path: '', url: 'http://localhost:8090')], contextPath: null, war: '**/*.war'
      }
    }
    stage ('DEV Approve') {
      steps {
      echo "Taking approval from DEV Manager"
        timeout(time: 7, unit: 'DAYS') {
        input message: 'Do you want to deploy?', submitter: 'admin'
        }
      }
    }
    stage ('Slack Notification') {
      steps {
        echo "deployed to DEV Env successfully"
        slackSend(channel:'your slack channel_name', message: "Job is successful, here is the info - Job '${env.JOB_NAME} [${env.BUILD_NUMBER}]' (${env.BUILD_URL})")
      }
    }
    stage ('QA Deploy') {
      steps {
        echo "deploying to QA Env "
        deploy adapters: [tomcat8(credentialsId: '268c42f6-f2f5-488f-b2aa-f2374d229b2e', path: '', url: 'http://your_dns_name:8090')], contextPath: null, war: '**/*.war'
        }
    }
    stage ('QA Approve') {
      steps {
        echo "Taking approval from QA manager"
        timeout(time: 7, unit: 'DAYS') {
        input message: 'Do you want to proceed to PROD?', submitter: 'admin,manager_userid'
        }
      }
    }
  }
}

Step 5
That's it. Pipeline as a code - Jenkinsfile is setup in GitHub.

Click on commit to save into GitHub.

Create Pipeline and Run pipeline from Jenkinsfile

1. Login to Jenkins
2. Click on New item, give some name and choose Pipeline and say OK

3. Under build triggers, choose Poll SCM,
Enter H/02 * * * *

4. Under Pipeline section. click on choose pipeline script from SCM

5. Under SCM, choose Git

6. Enter HTTPS URL of repo and choose credentials - enter user name/password of GitHub.
Script path as Jenkinsfile

7. Click on Apply and Save
8. Click on Build now.

You should see pipeline running and application is deployed to Tomcat.

What is Source Code Management (SCM) | What is Version Control System

Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.

If you are a software developer or web designer and want to keep every version of a file or layout (which you would most certainly want to), a Version Control System (VCS) is a very wise thing to use. It allows you to revert selected files back to a previous state, revert the entire project back to a previous state, compare changes over time, see who last modified something that might be causing a problem, who introduced an issue and when, and more. Using a VCS also generally means that if you screw things up or lose files, you can easily recover. In addition, you get all this for very little overhead.

Version control systems are two types:
1. Centralized version control system
2. Distributed version control system

Centralized Version Control Systems
CVCS have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.

 

The most obvious is the single point of failure that the centralized server represents. If that server goes down for an hour, then during that hour nobody can collaborate at all or save versioned changes to anything they’re working on. If the hard disk the central database is on becomes corrupted, and proper backups haven’t been kept, you lose absolutely everything — the entire history of the project except whatever single snapshots people happen to have on their local machines. 

Distributed Version Control Systems

Git is a popular distributed version control system. In Git, developers don’t just check out the latest snapshot of the files; rather, they fully mirror the repository, including its full history. Thus, if any server dies, and these systems were collaborating via that server, any of the client repositories can be copied back up to the server to restore it. Every clone is really a full backup of all the data.

developers clone the remote repo into local machine which is called local repo. When they clone in local machine, all history is copied into local repo. After making code changes, when they commit the code, it goes into local repo with new version. Then they can push code changes into remote repo where it is available to others. Client and remote server will have full repository.

Click here to learn how Git is different that traditional version control systems?

What is Tomcat | Why we need Tomcat Container?

What is Tomcat | Why we need Tomcat Container?

• Apache Tomcat is a open source java based web server
• It is also a web container for deploying Java based web applications - Java servlets and JSPs
• It is one of mostly used web servers for hosting java web applications. 

Web application (or webapp) unlike standalone application, runs over the Internet. Examples of webapps are google, amazon, facebook and twitter.

Apache Tomcat is usually used as a Servlet Container even though Tomcat has a fully functional HTTP Server to serve static content. In most of production, Tomcat is used in conjunction with Apache HTTP Server where Apache HTTP Server attends static content like html, images etc., and forwards the requests for dynamic content to Tomcat. This is because Apache HTTP Server supports more advanced options than that of Tomcat.

Tomcat is both Web server and web container

Generally, a program that accepts incoming HTTP connections is called a web server. In that case apache tomcat is a web server as it supports HTTP protocol and it is also a web container as it supports Java server pages (JSP)/servlet,Application programming interfaces(APIs) as well. 

What is Maven - Why We need Maven - Maven Introduction | Maven Tutorial

What is Maven?

Maven is a popular tool for building and managing any Java based projects. It allows the developer to create projects using Project Object Model and plugins. It helps to build projects, dependency, and documentation. Its development process is very similar to ANT. However, it is much advanced than ANT.

What Maven does ?

• Compilation of Java Source Code
• Execute Tests (unit tests and functional tests)
• Packaging the compiled code into JAR,WAR, EAR artifacts
• Upload the packages to remote repositories (Nexus, Artifactory)

Maven pom.xml file

POM is an acronym for Project Object Model. The pom.xml file contains information of project and configuration information for the maven to build the project such as dependencies, build directory, source directory, test source directory, plugin, goals etc.

Maven reads the pom.xml file, then executes the goal. pom.xml should have 4 important information.

<project>

  <modelVersion>4.0.0</modelVersion>

  <groupId>com.mycomp.dept</groupId>

  <artifactId>MyWebApp</artifactId>

  <version>1.0.0</version>

</project>

1. project - It is root element of pom.xml 
2. modelVersion- sub-element that specifies modelVersion, it should be set to 4.0.0 
3. groupId —will identify your project uniquely across all projects, ex:ebs.obill.webs, com.companyname.project
4. artifactId — is the name of the jar without version(keeping in mind that it should be jar-name friendly)
5. version — if you distribute it then you can choose any typical version with numbers and dots (1.0, 1.1, 1.0.1, …)

Create a Java project using Maven
The following command will create a Java application called MyWebApp

mvn archetype:generate -DgroupId=com.capone.af -DartifactId=MyWebApp -DarchetypeArtifactId=maven-archetype-webapp -DinteractiveMode=false

Maven Project structure

The src directory is the root directory of source code and test code.
The main directory is the root directory for source code related to the application itself, not test code.
The test directory contains the test source code.
The java directories under main and test contains the Java code for the application itself which is under main and the Java code for the tests which is under test.
The resources directory contains the resources needed by your project.
The target directory is created by Maven. It contains all the compiled classes, JAR files etc.

Maven Build lifecycle

The Maven build follows a specific life cycle to deploy and distribute the target project.
There are three built-in life cycles:

• default: the main life cycle as it's responsible for project deployment
• clean: to clean the project and remove all files generated by the previous build
• site: to create the project's site documentation

Maven Phases

A Maven phase represents a stage in the Maven build lifecycle. Each phase is responsible for a specific task.
Here are some of the most important phases in the default build lifecycle:

Build Phase	Description
validate	Validates that the project is correct and all necessary information is available. This also makes sure the dependencies are downloaded.
compile	Compiles the source code of the project.
test	Runs the tests against the compiled source code using a suitable unit testing framework. These tests should not require the code be packaged or deployed.
package	Packs the compiled code in its distributable format, such as a JAR.
install	Install the package into the local repository, for use as a dependency in other projects locally.
deploy	Copies the final package to the remote repository for sharing with other developers and projects.

Maven Architecture Diagram