Tutorials

 Hye Guys !!!

Adding here some tutorials for learning purpose. Please go though it once and share some thoughts, ideas in this world of DevOps !!!!!!!!!!!!!!!!!

Tutorials :

Azure Templates :

Create and Deploy your first ARM template

Add Resources

Add Parameters

Add Template Functions

Add Variables

Add Outputs

Use Exported Templates from Azure Portal

Use Azure QuickStart Templates

Add Tags

Use Parameter Files

Create A Pipeline

Developing ARM Templates using Azure Bicep

Deploying Web Applications Using GitHub Actions

Azure SQL Database


CircleCI - Configure Python Application


Google Cloud Build

Build and Test Go Applications

Build and Test Python Applications

Build and Test Java Applications

Build and Test Node.js Applications


GitLab CI

Create and Run Pipeline

Create Complex Pipeline


Bitbucket Pipeline

Creation of Pipeline

Creation of Fast Pipeline


Prometheus

Getting started with Prometheus

Visualizing metrics with Grafana

Grafana - First DashBoard


ELK Stack

ElasticSearch

LogStash

Kibana

Creation of Perfect Kibana DashBoard


Bash Scripting for CICD

PowerShell Scripting for CICD


Comments

Post a Comment

Popular posts from this blog

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Agile Retrospective

Image
  Guide to agile retrospectives for continuous improvement An agile retrospectives is an opportunity for agile development teams to reflect on past work together and identify ways to improve. Agile teams hold retrospective meetings after a time-boxed period of work is complete (typically a sprint lasting two to four weeks). During the agile retrospective, the team discusses what went well, what did not go as planned, and how to make the next work period better. Even if you are not on a development team, you can probably relate to the concept of retrospection. Have you ever worked hard on something only to realize later that you should have done it differently? It is not always a good feeling, but the solutions you uncover in hindsight can be valuable input for your next try. The same goes for your successes — acknowledging what went well and is worth repeating can be just as impactful. What is an agile retrospective? In short, an agile retrospective is a meeting...
Read more

Agile product management

Image
  What is agile product management? How do we define agile product management? It is a product development philosophy that emphasizes a flexible and human — rather than a rigid process- or tool-oriented — approach to defining product strategy and carrying out work. Teammates focus heavily on customer feedback to make improvements and adjust roadmaps throughout the product management process. This creates more responsive teams, leads to quicker iterations, and creates a more lovable experience overall. Benefits of agile product management Agile redefines how product managers think about planning and building products. Traditionally, new customer experiences were planned, designed, implemented, and tested in a step-by-step way. This meant that new functionality was delivered sequentially. Once requirements were defined and handed off to the development team, it was difficult to make any changes. The failure rate of large-scale and lengthy software development proj...
Read more