Project Batch 3

   MULTISHOP        is a big conglomerate and has various locations in both warehouses and stores world wide. They currently have a legacy web Application written in Java and hosted by their private server.

It usually takes 5hrs to update their application and updates are manual, which incurs a lot of downtime and is affecting their business because clients get locked out which gives their competitors upper hand.

Your Task is to migrate this Application into the cloud and implement Devops Practices to their entire Software Development Life Cycle

You should show concepts that implement Plan --Code--Build--Test--Deploy--Monitor

TASK A: Version Control The MultiShop Project

Plan & Code

 Your Project Supervisor will provide you the link to access the private repository where the code currently lives. and You can clone this repo and make it yours with the same repository name.

(You can only use GitHub)- 

1) Set up 2 repos, a Build Repo to store all the code base and a Deployment Repo to store all your deployment scripts and name them accordingly as you see below(in green): 

• Build repo : MultiShop_Build  
• Deployment repo: MultiShop_Deploy  

2)Git branching Strategy for MultiShop_Build

• main
• release: eg    release/release-v1
• feature:   eg  feature/feature-v1
• develop

3)Git branching Strategy for MultiShop_Deploy

• master
• feature eg feature/feature-v1
• develop

TASK B Acceptance Criteria: 

You need to host the code on a static website (s3 bucket) so as to avoid interruption of the main server. then go ahead and fulfil Task C and the rest

TASK C: Set up your Infrastructure

1. Set up your Environment: DEV, QA and PROD 

Provision 3 Apache Tomcat Servers (You can only Use Terraform with preinstalled script)You can host this use any cloud provider - Aws, Google Cloud, Azure but AWS is preferred

i. DEV - t2micro -8gb

ii. QA(Quality Assurance) - T2Large-20gb

iii. PROD - T2Xlarge-30gb

Linux Distribution for Apache Tomcat Servers: Ubuntu 18

2. Set up your Devops tools servers:

(These can be provisioned  IAC Tool, and hosted on only ubuntu 22, I also expected this to be done with a preinstalled script)

1 Jenkins(CI/CD) t2 xlarge 20gb

1 SonarQube(codeAnalysis) t2medium 10gb

1 Artifactory Server T2xl - 10gb

TASK D: Set Up Automated Build for Developers 

The Developers make use of Maven to Compile the code

a. Set up a C/I  Pipeline in Jenkins using Jenkinsfile 

b. Enable Webhooks in github to trigger Automated build to the Pipeline Job

c. Help the developers to version their artifacts, so that each build has a unique artifact version

Pipeline job Name: MultiShop_Build

Pipeline should be able to checkout the code from SCM and build using Maven build tool, Provide code analysis ,codecoverage with sonarqube and upload artifacts to artifactory, Send slacks to the team and provide versioning of artifacts

Pipeline should have slack channel notification to notify build status

i. Acceptance Criteria:

 Automated build after code is pushed to the repository

1. Sonar Analysis on the sonarqube server

2. Artifact uploaded to artifactory

3. Slack Channel Notification

4. Each artifact has a unique version number

5. Code coverage displayed

TASK E: Deploy & Operate (Continous Deployment)

a. Set up a C/D pipeline in Jenkins using Jenkinsfile

create 1 CD pipeline jobs for each env (Dev, QA, Prod)

Pipeline job Name:eg MultiShop_Dev_Deploy, MultiShop_QA_Deploy, MultiShop_Prod_Deploy

i. Pipeline should be able to deploy any of your LLE (Dev,  Qa) or HLE (Prod ) 

You can use DeploytoContainer plugin in jenkins and deploy to either  Dev, Qa or  Prod

ii. Pipeline should have slack channel notification to notify deployment status

iii. Deployment Gate

1. Acceptance criteria:

i. Deployment is seen and verified in either Dev, Qa or Prod

ii. Notification is seen in slack channel

TASK F: Monitoring

a. Set up Continuous monitoring with Datadog by installing Datadog Agent on all your servers

 Acceptance criteria: 

 i All your infrastructure Sever metrics seen on Datadog Server

ii Tag all your servers on the Datadog dashboard

TASK G: Dockerize Application

a. Automate the deployment of the Application into a docker image and write a deployment file and service file for it to be be deployed into K8s Cluster:

• 
  

Acceptance Criteria:

i. Deploy new artifact from dockerhub to Kubernetes

ii. App should be viewable in Grafana Dashboard

Lead Architect - Remzy

• Each Team/Person is to work independently with their supervisors to complete this project.
• Every Task is expected to be completed within 1 week
• We are adopting Agile style so each Team/Person is expected to have 15mins Daily Stand up meetings with your supervisors or in some cases the Lead Architect where you will discuss your progress(what you did yesterday, what you will do today, How far you are in achieving your goals and give general updates) 
• This will be a 1 week Sprint After which you will have a Demo to Present all your accomplishments.
• Please Note: DOE(Devops Engineers) and Architects from other establishments have been invited to your Demo so be prepared

Git Branching Strategy

 GIT BRANCHING STRATEGY

Once you start your journey into software development, it won’t take long for you to run into Source Control Management (SCM) systems. By far the most popular of them all is Git. 

Like most other SCMs, Git helps you manage your code in a way that allows for collaboration with team members. At the very core of Git, you will find that branching is one of its most helpful features.

Branching is what allows multiple developers to work on the same project without interfering with what the others are doing. With branching, each developer works on their own branch, and once they are ready to move it into production, they get their branches merged. 

In this guide, you’ll learn why Git branching is so valuable and get introduced to three different branching strategies.

Why is Git branching important?

Before we jump into the different branching strategies, you should know why they’re needed and why branching is so necessary in the first place. 

Branching helps you collaborate with your team members without stepping on each other’s toes. Git branching makes it possible for a full software development team to work on the same codebase simultaneously. However, there are other reasons why you need a branching strategy.

A branching strategy allows you to incorporate Git branching directly into your workflow. The most common use case is to enable Continuous Integration and/or Continuous Delivery. By using different branches, you can run automated tests every time something is pushed to a specific branch, making sure the code works before it gets merged into the production branch.

Automated tests aren’t the only type of tests you can do when you start implementing branching. You can also use different branches to perform A/B testing, deploy the code from two different branches, and redirect customers to one application or the other. This allows much finer control of what is running in the “main” branch that is considered production.

Types of Git branching

There are multiple types of Git branching strategies you can use for your projects. The three branching strategies listed below are a fraction of all the different strategies that exist; however, they are the three most popular strategies at the time of writing.

Git Flow

Git Flow is by far the most popular Git branching strategy out there, and it’s one of the oldest still in use today. It centers around having two branches: "main" and "develop." The principle behind this strategy is that all the code being developed is merged to the develop branch. Once you’re ready to make a release, you open up a pull request (PR) into the main branch. Essentially, this means that every commit in the main branch is a release in itself.

This doesn’t mean that every developer should be pushing into the develop branch every time they have something they need to add to the codebase. Instead they rely on what’s known as feature branches. As the name suggests, a branch is created for each new feature. The team can work on this feature branch until it’s ready to be merged into develop. Typically, at this point the feature is done.

With the feature branch done and ready to be merged into develop, it’s up to the team to decide how exactly they want to accomplish this. Many teams opt for a CI/CD approach and get the branch automatically tested, as well as reviewed by either team members or someone else with insight into the codebase. Once the feature branch has been merged into develop, it is deleted. At this point, you can either wait for more features to be merged into develop, or you can get develop merged into main for a release. In the end, Git Flow is highly defined and leaves teams with very little to decide for themselves, which can be a good thing as it leaves less work on the implementation.

GitHub Flow

Whereas Git Flow is a defined process, GitHub Flow is a bit looser on the concepts, allowing each team to define the way it works best for them. In reality, GitHub Flow doesn’t so much define the parameters on how each new branch should be created, but rather focuses on how the different branches should interact. One big difference from Git Flow is that it doesn’t have any develop branch. All new branches are built out from main and merged directly back into main.

So if GitHub Flow doesn’t dictate what branches need to be developed, what does it dictate? First of all, it defines that branches do need to be created, and that they should be created from main. From here, you can treat your branches however you please. In terms of the flow, there’s no difference between a branch that’s meant for a hotfix or for a full feature.

The other thing that GitHub Flow defines is the need to create a PR to get things merged into main. The PR needs to be viewed as a collaboration tool, where team members can comment on features and code. All in all, GitHub Flow does mean that teams have to work a bit more on the implementation to figure out what makes the most sense, but this also means that it comes with a lot of flexibility.