Jenkins and Artifact Management

12.1 Assignment Bank and Submission

12.1.1 The Five-Problem Bank

Five assignment statements sit in a problem bank, and you choose your own track. Why would a course design its assignments this way instead of giving everyone the same task?

Every assignment is individual work. The problems were designed to stay in line with the course content and with experiential learning: rather than forcing everyone through the same task, each student can opt for the stream where they want to explore more. That is why the bank was discussed openly in class before being published — so doubts could be cleared here instead of through a flood of emails later. The documents and instructions go up on the portal the same day.

A useful way to read the choice is to map it to career direction. Problem 1 (Git and GitHub) and problem 3 (Jenkins CI/CD) are the backbone of the software-delivery track most DevOps engineers work in daily; problem 2 (Selenium) is for people heading toward the testing and quality-assurance side; problems 4 and 5 are for management and leadership roles that need to understand DevOps as a process rather than operate its tools. Whichever you choose, the assignment is the same kind of learning device: a small, well-scoped project you complete alone, end to end, with the course's toolchain.

12.1.2 Lab Track: Git and GitHub

The first lab assignment is purely about Git and GitHub, worked through Git Bash. The core motive is to become genuinely comfortable with Git commands — the assignment exists so you get hands-on practice issuing, combining, and debugging commands in a terminal.

Git is the version control system that nearly every codebase in industry runs on, and Git Bash is the terminal environment where Windows users run Git commands exactly as they would on Linux. The assignment trains the exact skill set a team member uses every day: staging changes, committing, branching, merging, pushing to a remote, and recovering when a command goes wrong. If someone prefers not to host on GitHub, Bitbucket is an acceptable alternative, but Git Bash practice itself is non-negotiable — the command-line habit, not the specific hosting site, is what the assignment is about.

The task list includes performing a set of operations on a repository and recording a demo of the work, which is explained in the submission section below.

12.1.3 Lab Track: Selenium

The second problem is for people in the testing domain who want to explore Selenium. You may navigate to any website of your choice — the instructor's own example was their institutional portal, and Amazon and Zomato were offered as other options — log into that portal, and interact with its elements. If the page has dropdowns or pop-up options, you identify those elements and drive the interaction through Selenium.

Selenium WebDriver is the industry-standard tool for browser automation: it opens a real browser, locates the elements on a page, and performs the same clicks, typing, and selections a human would. It is free to download, so there is no cost barrier. The shared sample script is written in Python because Python is easy to work with, but the language is your choice: candidates who are strong in Java can write the Selenium script in Java instead — Selenium's APIs exist in both languages.

A practical tip from the walkthrough: right-click a page and choose Inspect to understand and identify the web elements on that page before writing code. The Inspect panel shows the HTML structure behind the page — the tags, classes, and identifiers — and that is exactly what your Selenium locators must reference. At least one or two use cases should be shown, such as login and then a post-login feature on the same site, so the submission proves not just one action but a small flow of real user behavior.

12.1.4 Lab Track: Jenkins CI/CD

The third problem is on CI/CD with Jenkins. You are expected to integrate Jenkins with GitHub — not to implement GitHub Actions in depth, but to make push and pull actions trigger Jenkins automatically. Whenever you push changes to the GitHub repository, Jenkins should automatically trigger the pipeline, and the changes made to the source code should be deployed onto staging and production environments.

Cloud choice is yours: AWS or Azure, whichever you feel comfortable pushing artifacts to. But cloud is not mandatory — the motivation is Jenkins experience, not cloud billing. If you prefer, create virtual machines on your local system, call one staging and the other production, and push the artifacts to those VMs. The assignment explicitly asks for a Jenkinsfile pipeline that completes the build, test, and deploy stages. The test stage does not need to connect to any external tool like Selenium — a simple echo message that says this is the test phase is acceptable, as long as the stage exists. What is being graded is the pipeline shape and the Jenkins workflow, not the sophistication of the test code.

For delivery versus deployment, the distinction is concrete: delivery happens on the staging environment, and deployment happens on the production environment. On AWS you could push the artifact to an S3 bucket or an EC2 instance; on a local setup you push to the staging and production VMs. The two-environment pattern mirrors what real teams run: a staging area that proves the build, and a production area that serves the users.

12.1.5 Case Study Track: Assignments 4 and 5

Problems 4 and 5 are theoretical, case study based assignments, kept for people in the classroom who are not heading toward a technology career — management or upper-ladder professionals who are learning DevOps to understand the process, the people, and the practices. There is no technical implementation expected here.

Each case study asks you to draw a component-based diagram and explain how product development and delivery can be accelerated with the help of DevOps, covering the process and the best practices that should be followed. The diagram is the key artifact: it shows the components of a system — such as source control, the build server, the test environments, and the deployment targets — and the arrows show how work flows through them. Because both problems are purely theoretical, whoever opts for the case study route must complete both 4 and 5: they are one assignment split into two parts, not two separate choices.

When a student asked whether sample answers would be shared for the case study (since for labs it makes sense to work through everything yourself), the instructor agreed to provide highlights so there is a starting point:

The highlights give a direction without removing the individual work: a starting point, not a finished answer. To make the requirement clearer on the portal, the instructor plans to keep assignment 4 as a single posting split into Case Study A and Case Study B; you are supposed to execute both A and B.

12.1.6 Submitting Your Work

Lab based exercises are evaluated through a demo: the instructor wants to see how you performed, not just what you wrote. If you are comfortable recording the screen, record the whole session and upload the video to a Google Drive link that will be shared on Teams as well as on the portal. Audio is optional — if you want to explain or discuss what you did, record it with audio. If you prefer not to record, screenshots work: capture each step — what you did, the next action, the next task — and build them into a document. Screenshots can be converted into a PDF and uploaded to the portal.

There is a second question about the demo itself — how much explanation the video needs:

The submission window is roughly four weeks: the deadline is the 6th of November, and the instructor considers that a comfortable amount of time. For lab assignments plagiarism is not a concern, because the work is purely performed by you — a performed demo cannot be copied the way a written answer can.

12.1.7 Schedule and Logistics

A few schedule notes were shared. There is no class next Sunday, because makeup examinations are scheduled for that day. The next contact session — the tenth — is on the 16th, and the tutorial session on the 18th is purely on Jenkins, covering the CI/CD pipeline hands-on. That tutorial is the direct preparation lane for assignment 3, so attending it with the assignment in mind pays off.

All assignment documents and instructions, including the Google Drive link, are published on the portal the same day, and questions can be directed to the WhatsApp platform afterwards to keep the instructor's inbox manageable.

12.2 Jenkins: History and Open-Source Roots

12.2.1 From Hudson to Jenkins

Why does the most widely used continuous integration server carry a name that sounds like a butler's title? The answer lies in a split that happened inside one project's history.

The fork is a textbook case of what happens when a tool's license changes under its community's feet. The community did not want to follow the code into a closed, paid product, so it followed the developer and the open source spirit instead. The project kept its history, its plugins, and its users — only the name changed. The community kept it completely open source — there is not a single restriction on working with Jenkins.

The plugin ecosystem is the visible proof of that community's size: Jenkins offers more than 1400 plugins, and the count has come close to 1500. Those plugins are small extensions — for Git, Maven, SonarQube, Docker, Slack notifications, and hundreds of other tools — that anyone can install to add a capability to the server. That volume of community-built extensions is exactly what makes Jenkins flexible, and it is also why configuration matters so much, as the next section explains: with so many parts to choose from, someone has to decide how they fit together.

12.2.2 Encapsulated Tools versus a Configurable System

Other continuous integration systems — TeamCity was named as an example — are what the instructor calls encapsulated solutions. Everything is readily available; you click on a function or install a plugin and the tool just works, which makes them easy to use. The tool hides its inner workings behind a finished, polished surface.

Jenkins is different: configuration has to be done thoroughly by the person using it. Nothing is hidden for you — every integration is something you wire together yourself, which means you have to understand what each piece does.

The SonarQube example makes this concrete. To connect Jenkins to SonarQube, installing the SonarQube plugin is not enough. You must go into the configuration settings of Jenkins, create a session key from your SonarQube instance, and interconnect the two. The plugin only adds the capability; the session key is the credential that lets the two servers trust each other, and the configuration settings tell Jenkins where the SonarQube server lives and how to reach it. Every integration you perform with Jenkins — Git, Maven, SonarQube, anything — requires you to understand the configuration part and how the communication between the tools is happening.

The instructor explicitly reframes this as an advantage rather than a drawback: the configuration work is a learning opportunity, because you understand the tool instead of just clicking it. But it is honest about the trade-off — there are people who do not want to invest time in that learning and just want CI/CD working, and for them the encapsulated tools in the market are the better fit.

The decision rule from class: if your goal is a working CI/CD pipeline with the least possible learning cost, pick the encapsulated tool; if your goal is to understand continuous integration and control how the pieces connect, pick Jenkins.

Real-world: this configuration depth is exactly why Jenkins job descriptions keep asking for pipeline-as-code and plugin administration skills — knowing how to wire Jenkins to SonarQube, Maven, or a cloud provider is a day-to-day industry task, not a classroom exercise. In companies running Jenkins at scale, the person who can connect and maintain these integrations is the person who keeps the whole delivery chain working.

12.2.3 Why Open Source Makes Jenkins the Learning Choice

There is also a syllabus-driven reason Jenkins is the tool of choice for this course: it is purely open source, so any candidate can perform any action on a local system without licensing constraints.

You can install it, break it, reconfigure it, and start over freely. That freedom is what makes hands-on learning practical — the entire CI/CD practice can be exercised on one laptop, which fits the course's DevOps goals. Compare that with a commercial tool: the license, the activation, and the cost all get in the way of the experiment where you deliberately break a configuration to see what happens. Open source removes that barrier, and the freedom to break things without consequences is exactly the environment in which people learn fastest.

12.3 Setting Up a Jenkins Environment

12.3.1 What You Need Before Installing

Jenkins is a continuous integration system, so the prerequisites for CI come bundled into its setup story. Three pieces must be in place before a first build can ever run.

By default Jenkins listens on port 8080; you can change the port if you need to, but the default is what most first installs use. Port 8080 is Jenkins' well-known address — when you open a browser to localhost:8080, you are talking to the Jenkins server on your machine.

12.3.2 First Login: Unlocking Jenkins

The first access to a new Jenkins instance is not a login — it is an unlock. Jenkins generates an initial admin password automatically, and the new instance asks you to enter it. Why an unlock and not a normal sign-in? On a fresh install there is no user account yet, and no one has set any password; Jenkins creates a one-time secret so the first human to reach the server can prove they control the machine it runs on.

Where to find the password depends on your operating system:

• On Linux, you read the Jenkins console log output, locate the generated password there, and unlock Jenkins with it. The password appears in the log lines printed when the Jenkins service starts.
• On Windows, the same initial admin password sits in a specific directory as a file — open that file, copy the password, and enter it. The path is shown in the setup screen itself.

Once unlocked, you create your own account and move on to customizing the instance. From that point the server behaves like any secured system: your credentials, your session, your builds.

12.3.3 Connecting Tools through Plugins

Jenkins is a continuous integration system, which means it is meant to be integrated with other tools and technologies. The customization mechanism is plugins — small installable extensions that teach Jenkins how to talk to a specific tool.

These exact instructions are already captured in the toolchain document in the reference document folder shared on Teams, so the reference folder is the place to check for the current paths and versions. Paths and versions drift as tools update, so the reference document — not memory — is the source of truth for what to install and where to point Jenkins.

12.3.4 Removing a Plugin

When you no longer work with a particular technology, you can save energy and storage by removing its plugin. There are two removal options.

The two options matter because the manual route works even when the UI is slow or the plugin is partially broken. When a broken plugin stops the UI from responding, you can still go to the filesystem and remove the .hpi file directly — the manual route is the escape hatch for exactly the situations where the friendly route is unavailable.

12.4 Jenkins Pipelines and the Jenkinsfile

12.4.1 What a Pipeline Is

The heart of Jenkins is the pipeline. A Jenkins pipeline is a suite of plugins that supports implementing and integrating a continuous delivery pipeline into Jenkins. The pipeline definition itself is written into a plain text file called the Jenkinsfile.

Think of the Jenkinsfile as the recipe card for the delivery process: it lists the ingredients (the tools and commands), the order of the steps (stages), and the oven temperature (the agent and environment). A team that changes its build process edits the recipe, not the machine.

12.4.2 Scripted versus Declarative Jenkinsfiles

There are two ways to create a Jenkinsfile. The instructor also described the declarative way as the descriptive way, because it states what should happen rather than how to program it.

The shorthand: scripted means the script lives in the Jenkins UI; declarative means the file lives outside it, next to your project. That placement difference is the whole point — a file next to the project is versioned, reviewed, and tracked like the code itself, while a script buried in the UI is tied to one server's configuration.

12.4.3 Three Ways to Structure a Pipeline

Even with the Jenkinsfile concept in place, there are three ways to structure a pipeline in Jenkins.

The difference between the two pipeline-as-code options is where the definition lives: option 1 is the scripted approach (defined inside the job), and option 3 embeds the script into the pipeline job itself. The chained-jobs approach (option 2) shows its structure through the jobs themselves — each job is one stage, and the triggers are the arrows between them.

12.4.4 Reading a Jenkinsfile

A minimal Jenkinsfile has a recognizable skeleton. It opens with a pipeline block, then declares agent any, and then carries multiple stages. In the example discussed, the stages are build, test, and deploy — the processes you want this Jenkinsfile to accomplish.

Each of these keywords has a precise meaning:

• agent — indicates that Jenkins should allocate an executor and a workspace for this part of the pipeline. agent any means Jenkins runs the pipeline on whatever available agent it finds.
• stages — describes the stages of the pipeline, the big phases of work.
• steps — the steps that have to be executed inside a particular stage.
• sh — executes the given shell command; the workhorse for Linux commands inside a stage.
• junit — a pipeline step provided by the plugins to perform unit tests, used in the example's test stage.

So the shape of the file mirrors the shape of the workflow: an agent to run on, stages to organize the work, and steps inside each stage to do the actual commands.

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                junit 'target/surefire-reports/*.xml'
            }
        }
        stage('Deploy') {
            steps {
                sh 'make publish'
            }
        }
    }
}

12.4.5 Build, Test, and Deploy in Detail

Each stage was walked through in detail.

The build stage performs compilation and creates an artifact. Whatever sub-actions are relevant for a build happen here: for a Maven project you run mvn clean and then mvn install — the two commands you use when working with Maven. clean removes the previous build output so the build starts fresh, and install compiles, tests, and places the resulting artifact into the local repository. Depending on the technology and the build process, you write the corresponding commands in the build step. Once the artifact is generated, you decide where to push it: the Archive Artifacts plugin archives the artifact to a target location, which in a real organization is generally the artifact repository.

The test stage runs the tests, and here the commands change with the kind of testing and the technology: if you are running Selenium tests the command is different from a JUnit run, and in the example the tests are JUnit tests. The test stage's job is to prove the build before anything ships; its output — the test reports — is what the team reads to decide whether to proceed.

The deploy stage decides where the artifact goes. The sequence taught is defensive: first check whether the build is null or not and whether the result is success; if the build is successful and there is output from the build process, then push the artifact — "make publish" — to the location you provide. That location can be an AWS S3 bucket, an AWS EC2 instance, an Azure cloud target, or even a folder on your local system. The pipeline does not care where; your job is to configure where.

12.4.6 Separate Jobs or a Single Jenkinsfile?

Before explaining the benefits of a single Jenkinsfile, the instructor paused and asked the class directly which structure they preferred — three separate jobs chained together, or one Jenkinsfile. The answers split the room:

The follow-up question — "can anybody tell me why the Jenkinsfile is better?" — produced the answer that the Jenkinsfile gets every benefit of a version control system, which is exactly the topic of the next section.

12.5 Why Use a Jenkinsfile

12.5.1 The Four Benefits

Once you have hands-on comfort with Jenkins, the Jenkinsfile becomes the preferred approach, and there are four concrete reasons.

2. It is durable. Pipelines written as a Jenkinsfile survive both planned and unplanned restarts of the Jenkins master. A script is a script — restarting the server does not erase the definition, because it is stored as text, not in some ephemeral UI state. When the master crashes and comes back, the pipeline definition is still there, waiting in the repository.

3. It can pause. Pipelines can automatically stop and wait for human input or approval before continuing. Jenkins has plugins for manual intervention, so you place a pause wherever a human gate is needed; the pipeline stops there and waits until a team member addresses the input, and then the pipeline continues — not restarts, continues. The pause is the pipeline's way of saying "this step needs a human decision," and after the decision it resumes from exactly where it stopped.

4. It is versatile. You can perform work in parallel. The Jenkinsfile lets you run independent branches of work side by side instead of waiting for everything serially. A test suite can split across several environments at once, and independent stages do not have to queue behind each other.

12.5.2 The End-to-End Pipeline Flow

The full pipeline picture ties the pieces together.

On your development system you push code and commit it to a repository; the specific repository and branch name now holds the code change. The moment the code change lands on that repository, the workflow kicks off:

1. SCM checkout — the first thing the pipeline does is pull the code from the version control system into the workspace.
2. Build — during the build, the process collects the dependencies needed by the build process. Different modules may use different technology: module one might be Java, while module two could be Python — and Python needs no build tool at all, you simply run that .py file and it is done. Depending on the technologies used, your build processes differ, and you can run those build processes in parallel.
3. Testing — you can perform parallel testing by pushing the artifact to several environments at once — the staging environment, a capacity environment, a user interface smoke test environment — and run the automation against each.
4. Deploy — the test results come back; if they are clear, the pipeline proceeds to deploy. Once the artifact is deployed on the production environment, the workflow ends.

12.5.3 Where Organizations Draw the Automation Line

Not every organization runs the full flow automatically. There are organizations that stop their automation at the testing phase and do the production release manually, by human action. And there are organizations that fully deliver the code all the way to the production environment through automation.

Both are real industry postures; the pipeline definition makes either one explicit. The posture is a choice baked into the Jenkinsfile: a pause before production means manual release, and no pause means full automation.

Real-world: in banking and healthcare, audit trails demand a named human who approved each release, so those teams run the pipeline to the deploy gate and stop; in consumer internet companies like Amazon and Netflix, the pipeline runs to production without a human in the path, because release frequency matters more than the approval ceremony. The same Jenkinsfile language expresses both postures — that is the practical value of a pipeline defined as code.

12.6 Multi-Branch Pipelines

12.6.1 What Multi-Branch Solves

The multi-branch pipeline project type is described as a genuinely interesting Jenkins feature. It enables you to implement different Jenkinsfiles for different branches of the same project.

Why would one project need several pipeline definitions? Think about microservice architecture based code: different branches mean different features, and different features may use different tools and technologies. A feature branch that introduces a new Node.js service has different build commands from a branch touching the Java backend — so you can keep a segregated Jenkinsfile for each branch, and each branch's pipeline matches its own technology.

Because discovery is automatic, the need for manual pipeline creation and job management disappears — new branches with a Jenkinsfile simply start flowing through CI/CD. A developer creates a branch, pushes a Jenkinsfile with it, and the pipeline exists. No one has to go into the Jenkins UI and create a job for the branch; Jenkins notices it on the next scan.

12.6.2 Creating a Multi-Branch Project

The creation walkthrough is short.

12.6.3 Triggers and Environment Variables

Two more settings matter.

First, the build trigger interval: you decide when the build should be triggered — periodically on an interval (every 30 minutes, every hour, whatever fits), remotely from a script, or immediately when the source code has been changed. The interval is the discovery heartbeat: with a 30-minute interval, Jenkins rescans the repository every half hour for new branches and new commits; the remote trigger lets an external script (or a repository hook) tell Jenkins to scan now; and the change-based trigger reacts the moment source code changes.

Second, extra environment variables help you identify what is running:

• The branch name variable carries the name of the branch this pipeline is executing for — for example master — so the team understands which branch a multi-branch job was created for.
• The change id variable is an identifier corresponding to some kind of change request, such as a pull request number; providing it makes clear for which particular change this branch was triggered or created.

The Jenkins portal has good tutorials and documentation for multi-branch pipelines, and the upcoming tutorial session will show a complete CI/CD pipeline, so this is a feature to explore hands-on.

12.7 Artifact Management

12.7.1 What Counts as an Artifact

An artifact is the output of any step in the software development process — "any step" on purpose. The word is broader than the compiled binary most people associate with "build output" — every phase of the lifecycle produces artifacts, and they all need managing.

The breadth matters for one reason: if every phase produces something worth keeping, then "manage your artifacts" is not a build-time chore — it is a whole-lifecycle discipline.

12.7.2 What an Artifact Repository Provides

An artifact repository serves three roles in an organization.

12.7.3 Tools in the Market

Several tools and technologies manage artifacts via an artifact repository. The named ones are JFrog (Artifactory), Nexus, Maven, and Helix Core.

JFrog has earned the most attention in the market when it comes to artifacts — the instructor notes you have almost certainly heard of it — but Nexus and Helix Core are legitimate alternatives, and Maven itself plays a role in artifact management alongside its build duties. Maven is the interesting case: it is primarily a build tool, but its local repository (~/.m2/repository) and its publish workflow make it a natural part of artifact handling in Java projects.

Real-world: JFrog Artifactory and Sonatype Nexus are the two names that dominate industry artifact storage; a typical enterprise CI/CD stack pairs Jenkins with one of them, with Maven handling the build-to-repository handoff. When you see a DevOps job description asking for "binary repository management," it is usually asking for Artifactory or Nexus.

12.7.4 Choosing a Tool: the Feature Checklist

When you opt for an artifact repository, you should check whether the tool supports the features that matter. The checklist given in class has five items:

• Secure — do you get secure access to the repository and its contents?
• Trusted — can you trust the tool and its ecosystem, including its community and maintenance?
• Stable — is the repository reliable under real use?
• Accessible — can you perform and also restrict accessibility, so access control to the repository is in your hands?
• Version — does the tool let you perform versioning, i.e., version control for the artifacts themselves?

These are the five things to look for when identifying and starting to use an artifact management tool. You can hold any candidate tool against this checklist: a repository that is fast but cannot version its artifacts fails the checklist, and so does one that stores artifacts but offers no access control.

12.7.5 Repository versus Shared Folder

The instructor turned the rationale for a repository into a class discussion: why is an artifact repository a better place for dependencies and libraries than a simple folder structure?

The follow-up points complete the picture. Because everyone consumes the same packages under the same names, compatibility problems shrink dramatically — one team's library version can no longer drift from another team's. Version control also makes it easy to track artifacts that are no longer being used, and remove them, which keeps the repository clean. An artifact repository also lets you treat your dependencies statically: some repository systems store only a single version of a package at a time, so to keep distinct versions of your project, you segregate the versions deliberately in the repository.

12.7.6 The "Works on My Laptop" Problem

There is a famous failure mode in software teams: during a demo, "it was working on my system — not sure why it is not working in this particular environment." An artifact repository is the structural fix for the works-on-my-laptop syndrome.

The repository even removes the dependency on the internet: it gives your organization its own universe. Whatever is written in the requirements.txt of your project is already available inside the artifact management repository, so the team can work without internet access. The deeper argument is ownership: relying on the internet for your dependencies means somebody else ultimately owns the availability and consistency of your build. Many organizations avoid exactly that by managing artifacts in their own repository rather than from public internet sources.

12.7.7 Single Source of Truth

An artifact repository organizes and manages binaries and their metadata in one central place, giving the organization a single source of truth for everything the build consumes and produces.

Concretely, it allows teams to easily find the correct version of a given artifact; developers can push to and pull from the artifact repository as part of the DevOps workflow; and because everyone is using the correct files, the repository improves the way teams work together and makes the CI/CD pipeline more reliable.

When you write the build script, instead of pointing the dependency download at local or internet sources, you provide the artifact repository URL so the build grabs those libraries and binaries from the central place. That one URL change, plus the central management behind it, is the ultimate benefit of running a binary repository manager in your organization.

12.8 Team Discussion: Git, Artifactory, and Real Practices

12.8.1 Keeping Artifacts Out of the Source Repository

A student shared their team's actual practice, and the discussion that followed is a useful window into real-world tooling choices.

The student clarified: the built library is not part of the code base — when you do a git clone you do not get the current library versions; instead, tags show the different versions of the code, and other teams refer to a particular version of the library — the code bundle, not the code. In their frontend work, the source code is totally different from the bundle. The instructor accepted the refinement: if the build is not part of what you clone, then keeping both on the same platform makes sense — but even then, segregate the two paths on the platform.

The instructor then broadened the point. Jenkins itself does keep artifacts: when you run a Jenkins build, the artifacts are created in the Jenkins workspace, and those artifacts carry a timeline — on which date that artifact was created. But when organizations want a standardized process, they follow the standards and opt for a dedicated set of tools for each job; they do not want Jenkins serving as both continuous integration and artifact repository at once.

Depending on the requirement set, an industry either opts for a dedicated tool or uses a single platform to complete the defined job — the student's team chose the GitHub platform, and that works for their defined job. The guideline is not a law; it is a default that teams may deviate from when their setup separates build output from cloned source, as the student's team does.

12.8.2 Git versus Artifactory

A student asked about version control: what is the difference between Git and Artifactory, and when should you use which one?

The exchange closed with a candid note: the instructor has not personally worked with Artifactory and did not want to confuse anyone by guessing about it, but the reasoning for Git is first-hand and detailed. A separate student question — "are you sure Artifactory is for artifact management?" — got the same honest answer: not entirely sure, since it has not been explored deeply, but the discussion group agreed it fits the artifact management role.

The takeaway that survives the uncertainty: an artifact management tool and a version control system are different categories of software, even though both deal with versions of things — Git manages source history, while Artifactory-style tools manage artifacts.

12.8.3 Docker Images in an Artifact Repository

Another student connected the dots to containers: if we store Docker images and the image artifacts in Artifactory, then Artifactory is the artifact repository.

That distinction was reinforced: an artifact management tool and a version control system are different categories of software, even though both deal with versions of things. Docker registries and binary repositories manage artifacts; Git manages source history. Container images are versioned products — exactly what an artifact repository is built to hold.

12.8.4 Guidance for Late Joiners and Non-Coders

A student who joined late asked for a quick overview of the assignments, since the class calendar had not shown the session. The overview for non-coders: for the Git and GitHub assignment you just need to learn the GitHub commands; for Jenkins you do not have to write code at all — hunt for any publicly available code on a GitHub repository, clone it into your local system, and start working; for Selenium you have to understand the script and how Selenium works, then start writing the script in the language you are comfortable with.

In short, Git and Selenium will be easy for non-coders, and Jenkins is also easy because the amount of code you have to write is very small. The three assignments were designed to be reachable without a programming background: the Git assignment is command practice, the Jenkins assignment reuses public code, and the Selenium assignment needs script understanding more than original programming.

12.9 Bonus: Master–Slave Topology and What Comes Next

12.9.1 The Master–Slave Setup

The Jenkins master–slave topology was introduced as a deeper topic to check in the tutorial session. It is the answer to a scaling question: what happens when one Jenkins server becomes the bottleneck for every build, test, and deploy in the organization?

The benefit of the division: the master is no longer doing heavy compilation work itself, so it stays responsive, and the team can add slaves when demand grows. The topology is why agent any in a Jenkinsfile works the way it does — Jenkins picks whichever available agent (slave) can take the work.

12.9.2 The Bonus Point Option

There is an optional bonus point attached to the Jenkins assignment. It is framed carefully: you can replace the three tasks of the assignment with a single bonus point task and score the same points — it does not carry extra points. It is an opportunity to explore more, not a requirement. If you skip it, there are no deductions; it is purely for your own learning.

The bonus work centers on the architecture: create the structure showing your Jenkins master server connected to all the different tools and technologies, with the artifact handling ready. You can simply showcase the architecture diagram in the documentation part and upload it over the portal. The diagram should show the master at the center, the connected tools (such as Git, Maven, SonarQube), and the artifact repository — the full topology this lecture has described in words, drawn as a picture.

12.9.3 What Comes Next

The agenda for this session was deliberately light — just Jenkins and artifact management. The next session is expected to be bulkier: it starts covering deployment strategies and managing infrastructure.

Those topics will take more time and more discussion, so this short session was the calm before that. Deployment strategies — how new versions reach production with minimal risk — and infrastructure management — how the environments themselves are created, configured, and maintained — are the natural follow-ons to everything in this lecture: a pipeline delivers the artifact, and the deployment strategy decides how the artifact lands.

Exam Guidance Summary

No exam-specific questions were discussed in this session, but there is substantial evaluation guidance tied to the assignments, which are graded outputs for the course.

• Deadline and window: assignment documents are published on the portal the same day, and submissions are accepted until the 6th of November — about four weeks of time, which the instructor considers plenty.
• Demo-based evaluation: lab assignments are graded through a demo — either a screen video uploaded to the shared Google Drive, or a screenshots document (convertible to PDF) uploaded to the portal. For video submitters, a short document naming you, the problem number solved, and the drive location must also be submitted on the portal, because grading requires a portal submission.
• Folder naming: use your Bits ID and the problem number you solved as the drive folder name so evaluators can identify the assignment being assessed.
• Plagiarism: the case study submissions go through a plagiarism check; copying content from internet sources drops the score once plagiarism exceeds 30%. Lab assignments have no plagiarism concern because the work is performed by you.
• Choice mechanics: pick any one of the three lab problems (Git and GitHub, Selenium, Jenkins CI/CD), or complete both case study problems (posted as Case Study A and B). The problems are individual work.
• Case study highlights: highlights are provided for the case studies so there is a starting point — a direction to work from, not a finished answer.
• Bonus point: the Jenkins bonus point replaces the three tasks with one task, scores the same marks, adds no extra points, and brings no deduction if skipped — it is for your own learning, and the architecture diagram can be showcased in the document submitted on the portal.
• Schedule relevance: the tutorial session on the 18th is purely on Jenkins (including the master–slave demo and a complete CI/CD pipeline), which directly supports assignment 3; makeup examinations take place next Sunday, when there is no class.

Key Industry Applications

• Jenkins in CI/CD: the industry-standard open source continuous integration server, with more than 1400 plugins (close to 1500) contributed by a large community; used to automate build, test, and deployment pipelines in countless organizations. Because it runs on Java and accepts plugins for nearly every tool, it remains the default choice for teams that want control over their delivery chain.
• Pipeline as code: Jenkinsfiles stored in the same repository as source code give teams version control, code review, rollback, durability across master restarts, human approval gates, and parallel execution — the modern way CI/CD definitions are managed. The file that says what to do with the code sits next to the code it acts on.
• SonarQube integration: connecting Jenkins to SonarQube requires installing the plugin plus creating a session key in Jenkins configuration — a realistic example of why Jenkins configuration skill is valued in industry. Code-quality gates in real pipelines work exactly this way: plugin plus credentials plus settings.
• Team practice with GitHub Actions: at least one team reported running pipelines entirely on GitHub Actions and storing built libraries on GitHub, referencing specific tagged versions from other repositories — a genuine industry alternative to a separate artifact server, provided the build output stays out of the cloned source.
• Artifact repositories: JFrog Artifactory and Nexus dominate industry artifact storage; organizations run them as a configurable proxy to public repositories, giving the build a single source of truth and letting teams work without internet dependency. Enterprise stacks typically pair Jenkins with one of them, with Maven handling the build-to-repository handoff.
• Microservice development: multi-branch pipelines are heavily used for microservice architecture based code, where each branch carries its own Jenkinsfile and Jenkins discovers it automatically — new branches flow through CI/CD without manual job creation.
• Cloud and local deployment: artifacts are pushed to AWS S3 buckets or EC2 instances, Azure cloud targets, or local staging and production virtual machines — delivery to staging and deployment to production are the standard two-environment pattern that the Jenkinsfile's deploy stage makes explicit.
• Test automation: Selenium WebDriver (free, Python or Java) for browser test automation, with element inspection via the browser's Inspect tool, plus JUnit test steps inside Jenkins pipelines — the same pattern real QA teams run against their web products.