Difference between Git and TFVC repository

Here is the difference between Git and any other repository such as TFVC, Subversion..
Git is a distributed repository...

Area	Git	Team Foundation Version Control (TFVC)
Repository type	Distributed	Centralized
Full History	Local machine	Central machine
Checkout	They clone the whole repository and do locally changes	Developer checkout working copy which is snapshot of a code
Work Offline	Yes	No
Branching and Merging	Reliable, used often, supports fat forward merge and 3-way merge	Reliable, use with caution
Operations speed	Fast and most are local	Network-dependent
Learning Curve	Needs a bit time	Relatively simple
Staging area	Supported to stash the temporary changes and retrieve it back later	Not supported
Collaboration model	Repository-to-repository interaction	Between working copy and central repo

How to transfer files from laptop to Amazon EC2?

One of the easiest ways to transfer files is to use secure copy method(scp) through command line as below:

scp -i "key_name.pem" copyme.txt ec2-user@aws_instance_name.com:/home/ec2-user

where you need to provide keyname, name of the file you are copying, user name and target directory.

You need to make sure the user has permission in the target directory.

How to set up Jenkins, Maven, Java, Git on Amazon EC2? Script for setting up EC2 with Jenkins, Maven, Java, Git

Here below is the shell script for installing Git, Jenkins, Java, Maven on RedHat Enterprise Linux...
Copy the below lines into a shell script, name as setup_ec2.sh. Give necessary permission to execute the shell script and execute it...

sudo yum -y update
sudo yum -y install wget
sudo yum -y install git

Java installation
wget --no-cookies --header "Cookie: gpw_e24=xxx; oraclelicense=accept-securebackup-cookie;" "http://download.oracle.com/otn-pub/java/jdk/8u11-b12/jdk-8u11-linux-x64.rpm"
sudo rpm -i jdk-8u11-linux-x64.rpm
sudo /usr/sbin/alternatives --install /usr/bin/java java /usr/java/jdk1.8.0_11/bin/java 20000
sudo /usr/sbin/alternatives --config java

download jenkins 
wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
rpm --import http://pkg.jenkins-ci.org/redhat-stable/jenkins-ci.org.key
sudo yum -y install jenkins
service jenkins start

Maven installation
sudo wget http://repos.fedorapeople.org/repos/dchen/apache-maven/epel-apache-maven.repo -O /etc/yum.repos.d/epel-apache-maven.reposudo sed -i s/\$releasever/6/g /etc/yum.repos.d/epel-apache-maven.repo
sudo yum install -y apache-maven

How to migrate from traditional monolithic to Microservices architecture? How to migrate to Microservices architecture?

We get these questions a lot from the teams we are coaching at my customer's work place

•  How to create microservices? 
•  How to break down our big monolith into microservices? 
•  What are some of the best practices, etc.?

Monolith and it's limitations

Before we deep dive into that topic, let's try to understand the limitations of monolith applications. Monolith is usually a single large web app (traditional WAR/EAR file) which has everything built-in. A small code change in UI requires a build, deployment and test, even you did not modify code in business or data layer.
Also, if you would like to scale out a layer, it is difficult as it requires a deployment of whole application on new instances. Here comes the Microservices to solve those issues.

Why Microservices?


Microservice is an architectural approach of breaking application (functional decomposition) into smaller services where each service can be independently developed, deployed with no limitation to technology stack. They also can be scaled out without impacting other services.

Microservices Characteristics

When designing microservices, we need to keep the following in mind:

• Each service should be treated as a component and should be independently deployable and able to be regression tested in isolation.
• Should be organized around business capabilities or domain.
• Based on Products, not projects – development team takes full responsibility of building software into production
• Decentralized governance
• Decentralized data management
• Infrastructure automation

How to migrate from monolith architecture into Microservices architecture?

If you are developing a large or complex application from scratch, start with microservices architecture by separating UI, business and data layers. If you already have a large app deployed to production which becomes a hard mountain to climb, you can address this problem in this way:

• Incrementally refactor your application into set of microservices without fully decommissioning the monolith app
• Implement any new functionality as Microservices
• Split the presentation components from the business and data access components
• Consider converting existing modules into services.

Best practices on developing Microservices
Here are some of the best but simple practices to consider when developing microservices:

• Design for failure (fault tolerance)
• Use one repository per service
• Each service should have independent CI/CD pipeline
• Each service should be loosely coupled
• Incrementally refactor your application into set of microservices when migrating from monolith
• Create a separate data store for each microservice.
• Deploy microservices in containers(Docker).

Challenges when implementing Microservices
Microservices architecture can be more complex than legacy systems. In turn, the environment becomes more complicated because teams must manage and support many moving parts. Let us see some of the challenges in implementing them:

• Tracing performance problems across tiers for a single business transaction can be difficult. This can be handled by correlating calls with a variety of methods including custom headers, tokens.
• Multiple databases and transaction management can be painful.
• Testing Microservices based application can be cumbersome.
• When more services are interacting, you increase possible failure points. So, they must be designed for fault tolerance.

How to filter or exclude files in SonarQube from scanning?

When you have third party Java script libraries in your web app, SonarQube may scan them and report defects. You can exclude it from Scanning in two ways as given below:

1. Add below entry in pom.xml
    <properties>
        <sonar.projectName>${project.groupId}:${project.artifactId}</sonar.projectName>
        <sonar.sources>app,src/main</sonar.sources>
        <sonar.exclusions>app/node_modules/**, src/main/webapp/**, app/dist/**</sonar.exclusions>
        <sonar.tests>src/test</sonar.tests>
     </properties>

2. You can also apply exclusions in SonarQube server as well, steps below

1. Go to sonarQube, select the project you need.
2. Go to administration,
3. Click on general settings,
4. Click on analysis scope
5. click on files, add files in textbox of Source file exclusions.

Top 10 Challenges in DevOps - Challenges in implementing DevOps - DevOps Challenges

DevOps...It is no more a buzzword..You hear this word pretty much every day during your coffee break at work.

Transitioning to DevOps requires a change in culture and mindset. One of the key benefits of DevOps is to remove silos (the communication barriers between teams) between development and ops teams.  Adopting DevOps to an organization always comes with a lot of challenges. Transitioning to DevOps requires a change in culture & mindset and much more. Let's look at the top 10 challenges and identify ways to overcome them.

1. Cultural change, change in the mindset - Cultural change is the first hurdle any company needs to overcome quickly for adopting devops fully. People should be bit open and welcome this new process change for embracing devops.
2. Not driven top-down, it should be bottom-up - Adoption should come up from ground up, can’t be a top down initiative. Devops starts with a couple of developers and ops folks working together on automation.
3. New tools.. new skills - Learning and Adapting to new set of tools are the key for practicing devops. Teams also should be open for hiring resources with CI/CD and devops skills if they don’t have one.
4. Not picking the right project to get started - It is better to find an existing application or small product (that has full SDLC life cycle) to remodel it into devops in incremental baby steps, earning small but solid wins along the way. This gives confidence to the teams.
5. Not moving away from legacy systems and infrastructure - By migrating monoliths into microservices architecture with automation and continuous delivery can bring faster development.
6. Business expecting quick results after DevOps adoption - Devops change does not happen overnight, it must be smooth and gradual. Business should have some patience to see results.
7. Not automating fully - Pipeline with leaks - Automation should be 100 percent. Pipelines also should integrate with code quality tools such as SonarQube. By doing few things still manually would enable for human error and can slow things down.
8. Not integrating QA automation in CI/CD pipelines - CI/CD pipeline is not fully complete without integrating QA automation execution. Both has to work together, not in silos.
9. Dev and Ops team having completely separate tools set - Both dev and ops need to work together and identify the right tools set. Need to ensure that is aligned within the goals for the organization.
10. Quantifying the impact to top management - This is probably the difficult challenge to overcome. Its first important to benchmark your current state. After that perform maturity assessment every two sprints and compare the results to see if there are any improvements. Looking at SonarQube dash board for reducing code quality defects. Also, scheduling a feedback session with actual users of the application to measure the success also helps.