Roles and Responsibilities of a DevOps Engineer

DevOps Engineer is somebody who understands the Software Development Lifecycle and has the outright understanding of various automation tools for developing software.




DevOps Engineer works with developers and the IT staff to oversee the code releases.

The main goal of DevOps is to increase the quality of the product to a great extent and to increase the collaboration of Development and Operation team as well so that the workflow within the organization becomes smoother.

DevOps Engineer should have
• Someone with experience of DevOps tools.
• Implement automated deployment and script configuration
• Implement DevOps solutions for team collaborations
• Achieve continuous integration and continuous delivery


Role of DevOps Engineer:

DevOps, there is more scope for visit changes in the code, which includes continuous automating and sending. It’s not anticipated that would compose the code ideal starting with no outside help yet picking the correct blend of coding, how to coordinate a few components of SQL information is important as a part of DevOps engineer role.

A DevOps engineer needs to connect with the team to deal with the difficulties emerging in the coding or scripting part which includes libraries and programming advancement packs to run the product on different OS and for sending.

DevOps Engineer is responsible for taking care of the IT foundation according to the business needs of the code which can be deployed in a hybrid multi-tenant environment which needs persistent checking of the execution. DevOps engineer must know about development tools which compose the new code or upgrade the current code.

DevOps Engineer needs to deal with code which needs to fit across multi-tenant environments including cloud. Henceforth a DevOps Engineer role a cross-practical part which oversees and handles programming that is assembled and deployed across challenging applications.



I am penning down some of my thought from my own experience as well some study I have done. 

Make sure that the pipeline is running smoothly – This is one of the most important tasks of a DevOps engineer to make sure that CI/CD pipeline is intact and fixing any issue or failure with it is the #1 priority for the day. They often need to spend time on troubleshooting, analyzing and providing fixes to issues.

Interaction with other teams – Co-ordination and collaboration is the key for DevOps to be successful and hence daily integration with Dev and QA team, Program management, IT is always required.

Work on Automation Backlog – Automation is the soul of DevOps so DevOps engineering needs to plan it out and I can see DevOps engineer spending lots of time behind the keyboard working on Automating stuff on daily basis.

Infrastructure Management – DevOps engineer is also responsible for maintaining and managing the infrastructure required for CI/CD pipeline and making sure that it's up and running and being used optimally is also part of their daily schedule. Ex. Working on Backup, High Availability, New Platform setup etc.

Dealing with Legacy stuff – Not everyone is lucky to work on latest and newest things and DevOps engineers are no exception hence they also need to spend time on legacy i.e. in terms of supporting it or migrating to the latest.

Exploration – DevOps leverage a lot from the various tools which are available, there are many options as open source so the team needs to regularly check on this to make sure the adoptions as required, this is something which also requires some effort, not on daily but regular basis. Ex. What are open source options available to keep the cost at a minimum?

Removing bottleneck – DevOps primary purpose is to identify the bottlenecks / Manual handshakes and work with everyone involved (Dev / QA and all another stakeholder) to remove them so team spends a good amount of time in finding such things and build the Automation Backlog using this. Ex. How we can get builds faster?

Documentation – Though Agile / DevOps stresses less on the documentation, it is still the important one which DevOps engineer does on a daily basis, Be it Server Information, Daily Week charted, Scrum / Kanban board or Simple steps to configure / backup or modify the infrastructure, you need to spend good amount of time in coming up these artifacts.

Training and Self Development – Self-learning and Training are very useful in getting a better understanding and many organizations encourage their employee to take the time out and do some of these and same holds true for DevOps folks as well, So learn something new every day...

Continuous Improvement as Practice – Last but not least, It’s up to the DevOps folks to build awareness on the potential of CI/CD and DevOps practices and building a culture of leveraging it for doing things better, reducing re-work, increasing the productivity and optimizing the use of existing resources. Go and talk to people to build the DevOps and Continuous Improvement culture.

I hope you have enjoyed my post on DevOps Engineer, got a question on the topic, mention it in the comments section.

Thanks

Agile Methodology in Brief

Agile is a software development methodology to build software incrementally using short iterations of 1 to 4 weeks so that the development is aligned with the changing business needs.

Instead of a single-pass development of 6 to 18 months where all the requirements and risks are predicted upfront, Agile adopts a process of frequent feedback where a workable product is delivered after 1 to 4 week iteration.





The agile software development emphasizes on four core values.

1. Individual and team interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan




Scrum Process:




Scrum Events

The Sprint

A sprint is a time-boxed period during which specific work is completed and made ready for review. Sprints are usually 2-4 weeks long but can be as short as one week.

Sprint Planning

Sprint Planning team meetings are time-boxed events that determine which product backlog items will be delivered and how the work will be achieved.

The Daily Stand-up

The Daily Stand-up is a short communication meeting (no more than 15 minutes) in which each team member quickly and transparently covers progress since the last stand-up, planned work before the next meeting, and any impediments that may be blocking his or her progress.

The Sprint Review

The Sprint Review is the “show-and-tell” or demonstration event for the team to present the work completed during the sprint. The Product Owner checks the work against pre-defined acceptance criteria and either accepts or rejects the work. The stakeholders or clients give feedback to ensure that the delivered increment met the business need.

The Retrospective

The Retrospective, or Retro, is the final team meeting in the Sprint to determine what went well, what didn’t go well, and how the team can improve in the next Sprint. Attended by the team and the Scrum Master, the Retrospective is an important opportunity for the team to focus on its overall performance and identify strategies for continuous improvement on its processes


Scrum Artifacts

Product Backlog

The product backlog is the single most important document that outlines every requirement for a system, project or product. The product backlog can be thought of as a to-do list consisting of work items, each of which produces a deliverable with business value. Backlog items are ordered in terms of business value by the Product Owner.

Sprint Backlog

A sprint backlog is the specific list of items taken from the product backlog which are to be completed in a sprint.

Increment

An Increment is the sum of all product backlog items that have been completed since the last software release. While it is up to the Product Owner to decide on when an increment is released, it is the team’s responsibility to make sure everything that is included in an increment is ready to be released. This is also referred to as the Potentially Shippable Increment (PSI).

Scrum Rules

The rules of agile Scrum should be completely up to the team and governed by what works best for their processes. The best agile coaches will tell teams to start with the basic scrum events listed above and then inspect and adapt based on your team’s unique needs so there is continuous improvement in the way teams work together.



How the Process is done? An Example!

Having read about the technical jargons of SCRUM. let me try to demonstrate the whole process with an example.

Example:

Step #1: Let’s have a SCRUM team of 9 people comprising of 1 product owner, 1 Scrum master, 2 testers, 4 developers and 1 DBA.

Step #2: The Sprint is decided to follow a 4 weeks cycle. So we have 1-month Sprint starting 5th June to 4th of July.

Step #3: The Product owner has the prioritized list of user stories in the product backlog.

Step #4: The team decides to meet on 4th June for the “Pre Planning” meeting.

The product owner takes 1 story from the product backlog, describes it and leaves it to the team to brainstorm on it.
The entire team discusses and communicates directly to the product owner to have clearly understood the user story.


In a similar way, various other user stories are taken. If possible, the team can go ahead and size the stories as well.

After all the discussion, Individual team members go back to their workstations and Identify their individual tasks for each story.
Calculate the exact number of hours on which they will be working. Let’s check how the member concludes these hours.

Total number of working hours = 9
Minus 1 hour for a break, minus 1 hour for meetings, minus 1 hour for emails, discussions, troubleshooting etc.
So the actual working hours = 6.
A total number of working days during the Sprint = 21 days.
Total number of hours available = 21*6 = 126.
The member is on leave for 2 days = 12 hours (This varies for each member, some may take leave and some may not.)
Number of actual hours = 126 – 12 = 114 hours.

This means that the member will actually be available for 114 hours for this sprint. So he will break down his individual sprint task in such a way that a total of 114 hours is reached.

Step #5: On the 5th of June the entire Scrum team meets for the “Planning Meeting”.
The final verdict of the user story from the product backlog is done and the story is moved to the Sprint Backlog.
For each story, each team member declares their identified tasks, if required they can have a discussion on those tasks, can size or resize it (remember the Fibonacci series!!).
The Scrum master or the team enter their individual tasks along with their hours for each story in a tool.
After all the stories are completed, Scrum master notes the initial Velocity and formally starts the Sprint.

Step #6: Once the Sprint has started, based on the tasks assigned, each team member starts working on those tasks.

Step #7: The team meets daily for 15 minutes and discusses 3 things:
What did they do yesterday?
What they plan to do today?
Any impediments (roadblocks)?

Step #8: The scrum master tracks the progress on a daily basis with the help of “Burn down chart”.

Step #9: In case of any impediments, the Scrum master follows up to resolve those.

Step #10: On 4th July, the team meets again for the review meeting. A member demonstrates the implemented user story to the product owner.

Step #11: On 5th July, the Team meets again for the Retrospective, where they discuss:
What went well?
What did not go well?
Action Items.

Step #12: On 6th July, the Team again meets for pre-planning meeting for the next sprint and the cycle continues.




Scrum Activity Tools

There are several tools that can be used extensively for tracking the scrum activities.

Some of them include:
Jira
XPlanner




I hope the above explanation helps you people.


All the Best for your career.

DevOps Content

--------------------------------------------------------------------------------------------------------------------------
                                                            DevOps Content
-----------------------------------------------------------------------------------------------------------

1. What’s Agile?

1. Agile methodologies and Scrum
2. Scrum Basics
3. User Stories
4. Estimating User Stories

2. DevOps Fundamentals

1. Recall Waterfall and Agile concepts
2. Differences within Dev and Ops Teams
3. DevOps and Agile – complementary concepts
4. DevOps Definition and need
5. DevOps history
6. Shift left approach to Ops
7. DevOps Principles
8. Benefits achieved using DevOps, trends towards faster delivery
9. DevOps Life Cycle and need for tools

3. Software Version Control

1. What is Version Control
2. Types of Version Control System
3. Introduction to SVN
4. Introduction to Git
5. Git Lifecycle
6. Common Git Commands
7. Working with Branches in Git
8. Merging Branches
9. Resolving Merge Conflicts
10. Git Workflow
11. Hands-on Exercise – 
Git Life cycle Commands
Pushing Code to Github
Stashing Code in git
Creating, Deleting Git Branches
Reverting a Push to GitHub
Merging branches using git merge
Merging branches using git rebase
Resolving merge conflicts using the git merge tool

4. Maven – as a Build tool

  1. Maven Objectives and usage
2. Maven Build Life Cycle and Goals
3. Maven build file POM.xml and its configuration elements with an example
4. Basic Maven commands – practical using CP-DOF case study

5. Containerization using Docker - Part I

1. Introduction to Docker
2. Understanding Docker Lifecycle
3. Components of Docker Ecosystem
4. Common Docker Operations
5. Creating a DockerHub Account
6. Committing changes in a Container
7. Pushing a Container Image to DockerHub
8. Creating Custom Docker Images using Dockerfile
9. Hands-on Exercise – 
Common Docker Operations
Creating a DockerHub Account
Committing Changes to a Container
Pushing container to DockerHub
Creating Local Image Repository
Building an Image using Dockerfile

6. Containerization using Docker - Part II

1. What are Docker Volumes
2. Deploying a Multi-Tier Application using Docker Network
3. Using Docker Compose to deploy containers
4. What is Container Orchestration
5. Container Orchestration Tools
6. Introduction to Docker Swarm
7. Deploying a 2-Node Cluster using Docker Swarm
8. Hands-on Exercise – 
Creating Docker Volumes
Using Docker Compose to deploy multiple containers
Deploying a Multi-Node Cluster using Docker Swarm
Deploying a multi-service app on Docker Swarm

7. Configuration Management using Puppet

1. Need of Configuration Management
2. Configuration Management Tools
3. What is Puppet
4. Puppet Architecture
5. Setting up Master Slave using Puppet
6. Puppet Manifests
7. Puppet Modules
8. Applying configuration using Puppet
9. Puppet File Server
10. Hands-on Exercise – 
Setting up Master-Slave on AWS
Testing Connection of nodes with Puppet
Creating a Manifest
Deploying Manifest on Node
Creating a Module
Deploying sample software on nodes using Puppet Modules and Manifests
Implementing a File Server Module on Puppet

8. Configuration Management using Ansible

1. What is Ansible?
2. Ansible vs Puppet
3. Ansible Architecture
4. Setting up Master-Slave using Ansible
5. Ansible Playbook
6. Ansible Roles
7. Applying configuration using Ansible
8. Hands-on Exercise – 
Installing Ansible on AWS
Creating a Playbook using YAML
Creating an Ansible Role
Using Roles in Playbook

9. Continuous Testing using Selenium

1. What is Continuous Testing?
2. Introduction to Selenium
3. What is Maven?
4. Using Maven with Selenium
5. Creating Test Cases with Selenium
6. Running Test Cases on Chromium Web Driver
7. What is Headless Mode?
8. Hands-on Exercise – 
Using Maven to import dependencies in Eclipse
Create a Sample Test Case for a website using Selenium
Implementing a headless test in selenium using Chrome WebDriver

10. Continuous Integration using Jenkins

1. Introduction to Continuous Integration
2. Jenkins Master-Slave Architecture
3. Understanding CI/CD Pipelines
4. Creating an end to end automated CI/CD Pipeline
 5. Creating Users + Manage + Assign
 6. Jenkins Catlight Notifications
 7. Jenkins Email Notifications 
 8. Jenkins Automated Deployment
 9. Jenkins Delivery Pipeline
 10. Jenkins Build Pipeline
 11. Jenkins Blue Ocean Window
 12. Jenkins Build Monitor View
13. Hands-on Exercise –
Creating a Jenkins Master Slave on AWS
Installing Plug-ins in Jenkins
Creating Jenkins Builds
Creating Scheduled Builds
Triggering Jobs using Git WebHooks
Using the Pipeline Plugin In Jenkins

11. Continuous Orchestration using Kubernetes
1. Introduction to Kubernetes
2. Docker Swarm vs Kubernetes
3. Kubernetes Architecture
4. Deploying Kubernetes using Kubeadms
5. Alternate ways of deploying Kubernetes
6. YAML Files
7. Creating a Deployment in Kubernetes using YAML
8. Services in Kubernetes
9. Ingress in Kubernetes
10. Case Study – Kubernetes Architecture
11. Hands-on Exercise – 
Setting up Kubernetes using kubeadm
Installing Kubernetes using kops and GCK
Creating a Deployment
Creating Services
Creating an Ingress
Demonstrating the use of Ingress, services, and deployments together

12. Continuous Monitoring using Nagios

1. What is Continuous Monitoring
2. Introduction to Nagios
3. Nagios Architecture
4. Monitoring Services in Nagios
5. What are NRPE Plugins
6. Monitoring System Info using NRPE plugins
7. Hands-on Exercise – 
Installing Nagios
Monitoring of different servers using Nagios


------------------------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------------------------