DevOps Bootcamp Mar 2024 Schedule | DevOps & AWS Azure Cloud Coaching by Coach AK | DevOps and Cloud Computing Online Classes |

The DevOps requirements in the IT market space is expected to grow by 35% by 2024. Getting a DevOps education now is a great investment into your future, which will pay off very fast!

You are in the right place to kick start your career in DevOps. DevOps is one of the top and hot IT skills right now. Currently almost all the employers are struggling to get right resources in their teams who can do the DevOps and automation work..You could be that person by attending this coaching program.

DevOps Coaching schedule Feb/Mar 2024 (promotions are available, pls contact Amy)

Date	Time	Type	When?
Mar 09th	09:45 AM CST to 11:25 AM CST on Saturdays 10:35 AM CST to 12:30 PM CST on Sundays	Weekends	Sat/Sundays
Mar 11th	6:00 to 8:00 PM CST	Weekdays	Mondays/Wednesdays

DevOps Coaching Highlights:

Comprehensive hands on knowledge on Git, Jenkins, Maven, SonarQube, Nexus, Terraform, Ansible, Docker, Kubernetes, Helm, Prometheus, Docker registry, Helm, AWS and Azure cloud platform.

To join DevOps Coaching classes, please contact Amy below:

Contact no# : +1(940) 344-5011

WhatsApp #: +1 (940) 344-5011
Email id: contact.devopscoaching@gmail.com
Contact Name: Amy

How to trigger a Jenkins job from another Jenkins job | Jenkins job Integrating another Jenkins Job | Jenkins Pipeline job triggering another Jenkins Job

Jenkins job can be triggered so many different ways. This article provides steps to trigger a Jenkins job from another Jenkins job. 

Pre-requisites:

• Jenkins up and running

Scenario #1(post build) - How to trigger a Jenkins job from another Free style Job?

1. Login to Jenkins instance.
2. Open your any existing freestyle build job.
3. Click on Configure

4. Go to post build action

5. Add post-build action --> click on Build other projects

6. Select job name(projects)  that you want to trigger by typing the name of the job and also check trigger only if build is stable

7. Save the job. 
8. Build job now, once the current job is built, it will trigger the next job immediately.
Check the console output of the current job, you will see id would trigger second job 

9. Go to the secondJob
Check console output. You will see the second job got triggered by first build job.

Scenario #2 (pre-build) - How to trigger a Jenkins job from another Free style Job?

1. Open your freestyle build job.
2. Click on Configure

3. Click on Build triggers

4. Check build other projects are built.

    

Select source job name which will be built first and then once the build is stable, it will be trigger this job. And also check trigger only if build is stable.

5. Save the job. 

6. Run the first job. once that job is successful, and then it will trigger this job.

Scenario #3 - How to trigger any Jenkins job from a pipeline Job:

pipeline {

    agent any

    stages {

        stage('Trigger Another Job') {

            steps {

                    build job: 'mySecondJob', wait: false

            }

        }

    }

}

Watch Steps in YouTube channel:

Different types of GitHub runners | GitHub runners various types | Self hosted vs GitHub Hosted runner

A self-hosted GitHub runner is a machine (physical or virtual) that you set up and manage to run GitHub Actions workflows. GitHub Actions is a CI/CD (Continuous Integration/Continuous Deployment) and automation service provided by GitHub. It allows you to define workflows in your GitHub repositories to automate build, test, and deployment processes. 

• GitHub-hosted runner
• Self-hosted runner
• Larger runner 
• ephemeral self-hosted runners (on-demand)

GitHub-hosted runners:

• These are runners provided by GitHub, and they are hosted on GitHub's infrastructure.
• GitHub provides various virtual machine configurations for different operating systems and environments.
• They are automatically scaled based on the demand, and you don't have to manage their infrastructure.
• GitHub-hosted runners have time and resource limitations, and you may need to consider these limitations based on your project's needs.

Self-hosted runners:

A self-hosted runner differs from the default GitHub-hosted runners in that it runs on infrastructure that you control. Self-hosted runners can be physical, virtual, in a container, on-premises, or in a cloud.

GitHub-hosted large runners:

GitHub offers customers on GitHub Team and GitHub Enterprise Cloud plans a range of managed virtual machines with more RAM, CPU, and disk space. These runners are hosted by GitHub and have the runner application and other tools preinstalled.

Ephemeral self-hosted runners:

GitHub Actions now supports ephemeral (i.e. single job) self-hosted runners to make autoscaling your runners easier. After a job is run, ephemeral runners are automatically unregistered from the service, allowing you to do any required post-job management. Ephemeral runners are a good choice for self-managed environments where you need each job to run on a clean image.

How to Implement CICD Pipeline using GitHub Actions | GitHub Actions Tutorials | GitHub Actions CICD Pipeline | Build Java WAR file using GitHub Actions CICD Workflow

What is GitHub Actions?

• GitHub Actions is a CICD platform to help you to automate tasks in software development lifecycle
• It allows you to automate various tasks in your software development workflow by defining workflows using YAML files.
• GitHub Actions are event-driven. i.e., when some event happens, you can trigger series of commands.
• GitHub Actions goes beyond just DevOps and lets you run workflows when other events happen in your repository.
• GitHub provides Linux, Windows, and macOS virtual machines to run your workflows, or you can host your own self-hosted runners in your own data center or cloud infrastructure.

GitHub Actions Workflow:

A workflow is a series of actions initiated once a triggering event occurs. For example, the triggering event can be some commit pushed to a GitHub repository, the creation of a pull request, or another workflow completed successfully. Event is the one which triggers the workflow.

Your workflow contains one or more jobs which can run in sequential order or in parallel. Each job will run inside its own virtual machine runner, or inside a container, and has one or more steps that either run a script that you define or run an action, which is a reusable extension that can simplify your workflow.

Workflows are defined by a YAML file checked in to your repository and will run when triggered by an event in your repository, or they can be triggered manually, or at a defined schedule.

Advantages of using GitHub Actions:

GitHub Actions offers several advantages for automating workflows in your software development process:

Integration with GitHub:

GitHub Actions is tightly integrated into the GitHub platform. This integration makes it easy to define, manage, and execute workflows directly within your repositories.

YAML-based Configuration:

Workflows are defined using YAML files, providing a simple and human-readable syntax. This makes it easy to understand, version, and share your workflow configurations.

Diverse Triggers:

GitHub Actions supports a variety of triggers for workflow execution, such as pushes, pull requests, issue comments, and scheduled events. This flexibility allows you to tailor workflows to your specific needs.

Parallel and Sequential Jobs:

Workflows can include multiple jobs that run in parallel or sequentially. This enables you to optimize build and test times by parallelizing tasks or organizing them in a specific order.

Reusable Actions:

GitHub Actions promotes code reuse through reusable actions. Actions are modular units of code that encapsulate a specific task and can be shared across different workflows and repositories

Supports a wide range of platforms and languages:

GitHub Actions supports a wide range of platforms and languages. This means that users can use the same automation tool for different projects and languages, which can simplify their workflows and reduce the need for multiple tools.

GitHub-hosted Runners:

GitHub provides virtual machines (runners) for executing workflows. These runners are pre-configured with various tools and environments, reducing the need for managing your own infrastructure.

Self-hosted Runners:

While GitHub provides hosted runners, you can also use self-hosted runners on your own infrastructure for greater control over the execution environment.

Community Actions:

GitHub Actions has a marketplace where you can find and share actions created by the community. This makes it easy to leverage existing solutions for common tasks in your workflows.

Secure:

GitHub Actions allows you to securely store and use secrets (e.g., API keys, access tokens) in your workflows, ensuring sensitive information is protected.

Sample GitHub Actions Workflow YAML for creating a WAR file using Maven

You will create this file .github/workflows/build.yaml inside GitHub Repo where your Java code is.

name: Build a WAR file using Maven

on:

  push:

    branches: [ "master" ]

jobs:

  build:

    runs-on: ubuntu-latest

    steps:

    - uses: actions/checkout@v3

    - name: Set up JDK 11

      uses: actions/setup-java@v2

      with:

        distribution: 'adopt'

        java-version: '11'

    - name: Build with Maven

      run: mvn clean install -f MyWebApp/pom.xml

Watch Steps in YouTube channel:

DevOps Interview Preparation Courses Offered by Coach AK - Please text or WhatsApp Coach AK on +1 (469)733-5248

  

Coach AK offers following services across the world online for $299 for new students and $249 for past students.

• Resume preparation services 
• Resume,  interview preparation services and mock interviews
• Resume and interview preparation services, provide DevOps questions and Answers with mock interview

Click here for the DevOps Interview preparation class schedule