Friday 27 April 2018

Using Spring RestTemplate for consuming Rest WebService



To simplify the REST service consumption Spring providers had introduced this Class called RestTemplate. This class is available in org.springframework.web.client package.

Maven dependency for this package

<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
<version>4.3.0.RELEASE</version>
</dependency>

A Example to use Spring REST template to consume REST web service with Basic Authentication.

package com.deploy.rest.jira;
/**
 * @author Kumar Gaurav
 *
 */

import java.util.Base64;

import org.springframework.http.HttpEntity;
import org.springframework.http.HttpHeaders;
import org.springframework.http.HttpMethod;
import org.springframework.http.MediaType;
import org.springframework.http.ResponseEntity;
import org.springframework.stereotype.Service;
import org.springframework.web.client.RestTemplate;

/**
 * The Class SpringRestTemplateExample .
 */

@Service
public class SpringRestTemplateExample {

/**
* Jira rest call .
*
* @param uri
*            the uri
* @return the all jira issues specific to project
*/
public static void main(String args[]) {
try {
String url = "any rest url to connect to tool using basic authentication";
//Currently I am using JIRA REST web service call to retrieve all issues for specific project.
                        RestTemplate restTemplate = new RestTemplate();

HttpHeaders headers = createHttpHeaders("UserName", "Password");
HttpEntity<String> entity = new HttpEntity<String>("parameters", headers);
ResponseEntity<String> response = restTemplate.exchange(url, HttpMethod.GET, entity, String.class);
/**
* We can use like below in order to get desired pojo as return type
*/

/* ResponseEntity<JiraIssues> response = restTemplate.exchange(url, HttpMethod.GET, entity, JiraIssues.class);
  JiraIssues jiraIssues = response.getBody();*/

System.out.println("Result - status (" + response.getStatusCode() + ")");
System.out.println("Response.getBody():->" + response.getBody());

} catch (Exception e) {
e.printStackTrace();
}
}

/**
* This method will help to get the basic authentication.
*
* @param userName
* @param password
* @return
*/
private static HttpHeaders createHttpHeaders(String userName, String password) {
String beforeEncode = userName + ":" + password;
String authAfterEncode = Base64.getEncoder().encodeToString(beforeEncode.getBytes());
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.APPLICATION_JSON);
headers.add("Authorization", "Basic " + authAfterEncode);
return headers;
}
}

Friday 20 April 2018

About Jenkins Installation


Jenkins Installation

When we look to install Jenkins then the official site of that is https://jenkins.io/


We can download the required file based on our OS. I downloaded Jenkins corresponding to windows version by clicking on the Windows link. We can see the below zip file downloaded via chrome 
which contains windows installer.


STEP - 1


STEP - 2



STEP - 3



STEP - 4



STEP - 5



STEP - 6

Open Jenkins.xml file and change the jenkins port as Jenkins default port is 8080 which is common to many apps. I placed 9090 as Jenkins Port to Run.


Now when we will http://localhost:9090/ we will be able to see the Jenkins dashboard.





Thursday 19 April 2018

About Jenkins

Jenkins


Jenkins - Features



  • Installation is more flexible than Go (Go is tied to Jetty and comes with it, but can be fronted with some other web server. Jenkins is not tied to any web server).
  • Extensibility. Plugins - About 600 of them.
  • Slightly easier to get started since it can work in “master-only mode”, where there is no slave node (“Agent” installation is a must in Go). 
  • Integration with VCS: Almost everything you’ve heard of and some you haven’t, because of plugins.
  • First class and often deep support for many tools: Maven (reads POM to figure out dependencies), Rake, Vagrant, Debian package building
  • Well-known. Community is pretty good, especially plugin writers.

Jenkins - Missing features (compared to Go)


  • Modelling capability is limited. While there are options to model in parallel-serial-parallel-serial approach using plugins, it is not very convincing. Support for multiple VCS for a job is supported through plugins which makes implementing a feature like fan-in difficult (plugin for fan-in will need to talk to VCS plugins)
  • Visualization and VSM - End-to-end visualization and auditability not at the level of Go. [how-to-use-jenkins-for-job-chaining-and-visualizations]
  • Fan-in: Jenkins does build incompatible builds resulting in lots of wasted build time. All the literature around the build flow plugin is still not convincing enough to say that it supports fan-in.
  • Go security seems more fine-grained than Jenkins’. Go allows per-user/group and per-pipeline authorization. Jenkins seems to allow this only at a global, per-user/group level.


Go CD VS Jenkins


1. Go CD is a best-of-breed tool for Continuous Delivery (CD).
    Jenkins is a general purpose automation tool and is built for Continuous Integration(CI).

2. Go CD aims to support the most common CD scenarios out of the box without any plugin installation where as Extensibility is core to Jenkins. Its flexibility attributes itself to plugins being critical to Jenkins’ functionality. So it depends heavily on plugins for pretty much any use case.

3. Go CD was built on the principles of [Continuous Delivery](https://continuousdelivery.com/). This is visible in its abstractions as pipeline is a first class concept. Go CD also encourages that there be only one way to implement the fundamental CD patterns. When you search for help on how to implement the various deployment pipeline patterns, you will generally find a single, well-known, well-tested answer.

With Jenkins 2.0, CD is implemented by the installation of a variety of plugins. Many common CD patterns (build an artifact only once, full traceability up and down stream, and more) are either impossible to implement or can only be cobbled together with fragile   combinations of plugins.

4. Although Go CD is built specifically with CD in mind, it has sophisticated features for continuous integration.

Jenkins is built for CI. Anything beyond that, requires plugins.



About Go Continuous Delivery


About GoCD


GoCD is an open source tool which is used in software development to achieve continuous delivery of software. It supports automating the entire build-test-release process from code check-in to deployment. It helps to keep producing valuable software in short cycles and ensure that the software can be reliably released at any time.

·        A Pipeline consists of multiple stages, each of which will be run in order.

·        A Stage consists of multiple jobs, each of which can run independently of the others.

·        A Job consists of multiple tasks, each of which will be run in order.

·        A Task is an action that needs to be performed. Usually, it is a single command.

·        A Material is a cause for a pipeline to run. This could be a commit made to a source code repository or a timer trigger.

·        Agents run the jobs assigned to them.


Go CD benefits


  • Visualization with features like Value Stream Map 
  • Fan-in support - Go does not build incompatible revisions reducing lot of wasted build time
  • Good modelling ability (pipelines, stages, jobs, tasks).
  • Easy parallelizability (jobs across agents, can use resources to tie jobs to a set of agents)
  • Traceability - from deployed build all the way back to source code commits
  • Security - Secure communication between agents and server, possible to configure Go to be https-only.
  • Fine-grained control of permissions
  • Collaboration - Go can be used across the organisation. Here teams can use it to do automated deployments. Dev teams can see where there commit has reached (unit tests, acceptance tests, QA env etc.), QA teams can see what build is deployed on what env. and other stakeholders can compare revisions to see what features / bugs are going into a release. 
  • Ability to segregate pipelines using groups, agents using resources and trying both together using environments. Using the “Environments” feature of Go to separate build pipelines from deployment pipelines.
  • One-click backup

Go CD - Missing features


  • Only a couple of extension points (plugins) - Go team is working to make more extension points available. Currently external Package Repository as material (for yum, rpm, etc. post Go 13.3) and Task Plugin (plugin support coming from Go 14.1, to be released soon) are available.
  • Custom email notifications not configurable enough.
  • Multiple server support

Facts about CI & CD

CI & CD

Continuous Integration (CI)  VS Continuous delivery (CD)  VS Continuous Deployment


Continuous Integration (CI) is a software engineering practice in which developers integrate code into a shared repository several times a day in order to obtain rapid feedback of the feasibility of that code. CI enables automated build and testing so that teams can rapidly work on a single project together.

Continuous integration is the process by which a developer’s code is integrated with the main code branch as quickly as possible. Continuous integration puts a great emphasis on testing automation to check that the application is not broken whenever new commits are integrated into the main branch.

Continuous delivery (CD) is a software engineering practice in which teams develop, build, test, and release software in short cycles. It depends on automation at every stage so that cycles can be both quick and reliable.

Continuous delivery takes CI one step further, with an emphasis not just on integrating code, but also making the code shippable at any time. Continuous delivery usually requires automated testing, so that the developers are confident that the code can be shipped Or we can say that Continuous delivery is an extension of continuous integration to make sure that you can release new changes to your customers quickly in a sustainable way. This means that on top of having automated your testing, you also have automated your release process and you can deploy your application at any point of time by clicking on a button.


Continuous Deployment is the process by which qualified changes in software code or architecture are deployed to production as soon as they are ready and without human intervention.

Continuous deployment is a term that is usually applied to cloud software systems, where software code changes are automatically deployed to production, in a safe way. Continuous deployment strategies usually involve incremental deployments that allow changes to be tested incrementally. Continuous deployment goes one step further than continuous delivery. With this practice, every change that passes all stages of your production pipeline is released to your customers. There’s no human intervention

Continuous Deployment is the act of deploying every addition to the mainline branch to the consumer. Continuous Deployment would happen after CI passes and the feature/bug fixes made were merged into the mainline/trunk branch. All the changes would be sent to the distribution/production environment.



Finally, we can conclude that

Continuous integration (CI) can mean one of two things:

1.     The work done by a continuous integration server, such as Jenkins or Bamboo

2.     The process of integrating changes into software at all stages of the delivery pipeline

Continuous Delivery is the frequent shipping of code to a given environment (such as test or production) via manual release.

Continuous Deployment is the automated release of code to a production environment.