Forem: Davide 'CoderDave' Benvegnù

Security Best Practices For GitHub Actions Secrets

Davide 'CoderDave' Benvegnù — Tue, 26 Sep 2023 03:01:10 +0000

Today we talk about security in GitHub, and specifically about how to properly use and configure GitHub Actions Secrets.

This article is part of a new GitHub Security Hardening series, so stay tuned for new articles about this topic.

Also, if you are new to GitHub Actions, I recommend you to check the intro video I made about the topic, there I cover all you can do with GitHub Actions.

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation.

Link to the video: https://youtu.be/2yHRq7aWDKM

If you rather prefer reading, well... let's just continue :)

Let's Talk About Secrets

We hopefully all agree that sensitive values should never be stored as plain text in workflow files, but rather as secrets.

Secrets can be configured at the enterprise, organization, repository, or environment level, allowing you to store sensitive information in GitHub, as I explained in this video.

Storing these secrets is not a problem as everything is safely managed by GitHub. They are even encrypted on the client side before reaching GitHub! However, using them can be problematic.

To help prevent accidental leakages, in fact, GitHub redacts any secrets that appear in run logs and replace their values with stars (***).

This redaction looks for exact matches of any configured secrets, as well as common encodings of the values, like for example Base64. There are however multiple ways in which a secret value can be transformed, and because of that this redaction is not 100% guaranteed.

As a result, there are some things we can proactively do, and good practices we should follow, to help ensure secrets are redacted and to limit other risks associated with secrets.

Don't Use Structured Data

First of all, if possible don’t use structured data as a secret. Using structured data can cause secret redaction within logs to fail, as redaction relies on identifying an exact match of the secret value.

For example, avoid using a blob of JSON, XML, YAML, or similar as secret value, this significantly reduces the probability that the secrets will be properly redacted.
Instead, create individual secrets for each sensitive value.

Again, this is not always possible, but doing so greatly reduce risks.

Register ALL Secrets

Another important step is to register all secrets used within workflows. If a secret is used to generate another sensitive value within a workflow, that generated value should be formally registered as a secret. This ensures that the value will be redacted if it ever appears in the logs.

For example, when using a private key to generate a signed JWT for accessing a web API, it's important to register that JWT as a secret. Otherwise, the JWT won't be redacted if it ever enters the log output.

It's important to note that registering secrets also applies to any sort of transformation or encoding. If your secret is transformed in any way (for example with Base64 or URL encoding), be sure to register the new value as a secret as well.

Let me know in the comments down below if you like me to produce an article and/or a video on how to register anything as a secret in GitHub Actions.

Audit How Secrets Are Handled

In addition, it is important to audit how secrets are handled. This involves reviewing how secrets are used to ensure they are being handled properly.

To do this, you can review the source code of the repository executing the workflow and check any actions used in the workflow. For example, make sure that secrets are not sent to unintended hosts or explicitly printed to log output.

After testing valid and invalid inputs, view the run logs for your workflow and confirm that secrets are properly redacted or not shown. It is not always clear how a command or tool you are invoking will send errors to STDOUT and STDERR, and secrets may end up in error logs. Therefore, it is good practice to manually review the workflow logs to ensure that secrets are properly handled.

Use Minimally Scoped Credentials

Next, it’s a good practice, and not only for GitHub Actions Secrets, using credentials that are minimally scoped.

Ensure that the credentials used in workflows have the minimum privileges required. Keep in mind that any user with write access to your repository also has read access to all the secrets configured in it.

Actions can access the GITHUB_TOKEN from the github.token context and you should ensure that this token is only granted the minimum required permissions. It is good security practice to set the default permission for GITHUB_TOKEN to read access only for repository contents.
The permissions can then be increased for individual jobs within the workflow file, as required.

Audit and Rotate Registered Secrets

Another thing we should all do when working with secrets is to audit and rotate registered secrets.

For example, we can periodically review the registered secrets to confirm they are still required and remove those that are no longer needed. I personally set this as a recurrent task for my team so every months we have a review of all secrets.

We should also rotate secrets periodically to reduce the window of time during which a compromised secret is valid.

Require Approval for Accessing Secrets

And final good practice, consider requiring review for access to secrets.

Not everyone may be aware of this, but you can use required reviewers to protect environment secrets. A workflow job cannot access environment secrets until a reviewer grants approval.

This is of course only available in GitHub Enterprise or on public repositories, but it is something you should definitely do if you can.

Conclusions

Let me know in the comments below if you have any other tip and best practices when working with GitHub Secrets.

Also, check out this video, in which I explain how to properly store Secrets in GitHub.

Like, share and follow me 🚀 for more content:

🆘 Get Help With DevOps
📽 YouTube
☕ Buy me a coffee
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast
💖 Patreon

GitHub: Composite Actions vs Reusable Workflows [Updated 2023]

Davide 'CoderDave' Benvegnù — Tue, 12 Sep 2023 08:27:39 +0000

Understanding the differences between Composite Actions and Reusable Workflows in GitHub Actions can be more complex than you think… especially after the latest changes GitHub made.

But hey, I’m here for you. Let’s find out together what those 2 features have in common, what the differences are, and when you should use one instead of the other.

Into

I’ve already written an article and made a video on this subject before, however that was almost 1 and a half years ago and, as many pointed out in the comments , GitHub has substantially changed the featureset since… so it’s time for an updated comparison.

Btw if you want to have a deep dive into either Composite Actions or Reusable Workflows, be sure to check the in-depth videos I made about them (here and here).

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation.

Link to the video: https://youtu.be/zc19mR3O4a4

If you rather prefer reading, well... let's just continue :)

About Composite Actins and Reusable Workflows

In general, Reusable Workflows are a way to avoid duplication as you can reuse the same workflow in multiple other workflows, and perhaps create a library of proven and effective workflows that can be centrally maintained.

Composite Actions, instead, allows you to combine multiple steps within one action. For example, you can use this feature to bundle together multiple run commands into an action, and then have a workflow that executes the bundled commands as a single step using that action.

And this brings me to the first difference between the 2: Visibility and Logging.

1. Visibility and Logging

I think this point is pretty important but often overlooked.

With Reusable Workflows you have a very rich log of what is happening, and every single job and step is logged independently in real time as you can see below:

This specific workflow has 2 jobs in it, and each job is logged together with its steps. All clear and organized.

This is not the case, however, with Composite Actions. As we have just seen, Composite Actions are a way to group multiple steps in one… this also means that when executing that step you don’t have visibility on all of the parts.

All you have is a single log of a single step... even if it contains multiple steps.

2. Jobs

Another difference, which is the biggest difference in my opinion, is about Jobs.

As we have said before, Composite Actions allow you to only have a flat list of steps. Therefore, you cannot have multiple jobs in a single Composite Action.

In fact, a Composite Action doesn’t even specify a job keyword, but uses runs instead, and can only be consumed from within a job in the caller repository.

Because of this, you can see a Composite Action basically like any other action you have on the marketplace.

The story is different, however, for Reusable Workflows.

They do define jobs inside them, and because of that you can have as many jobs as you want in a single Reusable Workflow.

And since they do use jobs, and you have to specify where the job will run, we can take this a little further: if your job needs to run on a specific runner or machine, you need to use Reusable Workflows.

3. Calling them

Next, and actually last, difference between Composite Actions and Reusable Workflows is how you call them, and this tightly relates to what we have seen previously.

Reusable workflows are called directly within a job definition, and not from within a job step.

You cannot, therefore, use GITHUB_ENV to pass values to job steps in the caller workflow. And, more importantly, you cannot add additional steps to the job which calls the reusable workflow.

Composite Actions, instead, can exclusively be called and used as a step in a job, which also means there could be (and that is usually the case) other steps in the job before and or after the Composite Action.

Make sure to keep this difference in mind when designing your Actions Workflows.

Conclusions

There used to be many more differences between Composite Actions and Reusable Workflow, but as of recording this video, the only ones still standing are the 3 differences we have just seen.

So, to recap, Reusable Workflows make it simpler to spin up new repositories and projects and immediately start using automation and CI/CD workflows with GitHub Actions that you know will work, and to reduce code duplication.

Composite Actions, on the other hand, allow you to pack multiple tasks and operations in a single step, to be reused inside a job.

Let me know in the comments below if you noticed any other point in which those 2 features differ, and if you prefer using Composite Actions, or Reusable Workflows… or both 😉

Also, check out this video, in which I talk about the new GitHub Actions Larger Runners and how to use them.

Like, share and follow me 🚀 for more content:

Azure Boards? Here's WHY!

Davide 'CoderDave' Benvegnù — Wed, 05 Jul 2023 04:01:45 +0000

Do you need a tool to help you organize your work and don’t know which one to use? Or are you thinking of using Azure Boards but you’re not quite convinced yet? Let me tell you why you should start using Azure Boards right now. Even if you are not hosting your code in Azure DevOps!

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation and demo.

Link to the video: https://youtu.be/T3_UNAA8onw

If you rather prefer reading, well... let's just continue :)

Intro to Azure Boards

Azure Boards is a standalone service within the Azure DevOps suite that helps teams plan, track, and discuss work across the entire software development process. It provides a flexible, customizable platform for managing work items, such as user stories, bugs, tasks, and issues, so you can track your work item's progress throughout the development lifecycle.

Azure Boards supports agile methodologies, including Scrum and Kanban, and provides a range of features and integrations to help teams collaborate and stay organized with dashboards, reports, and notifications.

Last but not least, Azure Boards doesn’t require you to have your code in Azure Repos or use Azure Pipelines for CI/CD… even tho of course it works even better if you do :)

11 Reasons to Start Using Azure Boards

Now that we have a basic understanding of what Azure Boards is and does, why should you use it?

Reason 1: Start Simply, Scale as you grow

First of all, it is very easy to start with it and allows you to scale as you grow.

Azure Boards offers predefined work item types for tracking features, user stories, bugs, and tasks, making it easy to start using your product backlog or Kanban board.

As mentioned before, it supports different Agile methods, so you can implement the one which suits you best.

Additionally, you can add teams as your organization grows to give them the autonomy to track their work as they see fit.

Reason 2: Use visual, interactive tools

Next reason is that Azure Boards has plenty of visual tools to help teams quickly see and share progress. As we have seen, you can use Kanban boards, which provide an intuitive and visual way to manage your projects, track work items, and collaborate with your team effectively, and product backlogs, which correspond to your project plan, the roadmap for what your team plans to deliver and include users stories, requirements and backlog items.

You can also use the built-in scrum boards and planning tools, and finally delivery plans, which allow to review the schedule of stories or features that your teams plan to deliver by showing the scheduled work items by sprint (iteration path) of selected teams against a calendar view.

Reason 3: Customize easily

Third reason to start using Azure Boards is that it is very easily to configure and customize all its parts through the user interface.

You can make your own versions of Kanban boards, taskboards, and delivery plans , as well as add custom fields, work item types, and portfolio backlogs.

This will make sure the tool adapts to your needs and processes, and won’t instead require you to adapt to the tool.

Reason 4: Use built-in social tools and communication

Another reason, the fourth, is the ease of communication.

Work item forms provide built-in discussions that you can use to capture questions, notes, and communication as they occur.

With this feature, you can maintain a history of what a team decides on any particular work item. An dyou can quickly bring a team member or an entire team into the conversation by using @name mentions.

Reason 5: Capture information, generous cloud storage

Fifth reason on my list to use Azure Boards is something we take for granted but in fact it’s not always the case: information and storage.

As I’ve mentioned before, work items are designed to track all the information you need to track. And this doesn’t stop to text. You can in fact edit in rich text, drag and drop inline images, and add larger attachments. You can add attachments up to 60 MB and as many as 100 attachments.

Also, you can link work items within a hierarchy or by simple related links. Each work item maintains a history of changes, so you can review what changed, who made the change, and when.

Reason 6: Find what you need quickly and get notified of changes

Sixth reason to start using the service is that Azure Boards provides easy-to-use tools to help you quickly find specific work items as your project grows.

You can follow work items to monitor updates and changes, use pivot views to show work items assigned to you, use the query engine to filter work items based on any field, and use ad-hoc search with quick inline filters.

You can also personalize your alerts for work items that are assigned to you or have been changed.

Reason 7: Monitor status and progress with built-in dashboards and analytics

Seventh, with Azure Boards you gain access to many tools to generate reports and to support tracking status and trends.

By using configurable dashboards, you can add one or more widgets to display the information and data you want, such as the bug burndown widget. Along with dashboards, you have access to the Analytics service. This service is optimized for fast read-access and server-based aggregations.

By using Analytics views and Power BI, you can create highly sophisticated reports on the project data of interest.

Reason 8: Integrate with Office

And if that wasn’t enough, eighth reason, Project managers who want to use familiar tools can import and export work item queries to and from Microsoft Office Excel or import and export work items using .csv files.

Excel supports adding work items, updating existing work items, adding links and attachments to multiple work items, and more. You can also use native Excel features to support other actions, such as summing a column, copy-and-paste rows, fill down data into cells, and more.

Reason 9: Extend functionality

You can gain even greater functionality by adding Marketplace extensions, many of which are free, and this is my reason number 9.

An extension is an installable plugin that adds capabilities to Azure DevOps and of course Azure Boards. You can find extensions within these products or in the Visual Studio Marketplace, under the Azure DevOps tab.

Also, by using the REST API, you can create your own extensions or tools to integrate with Azure DevOps Services.

Reason 10: Get updates via a mobile browser

Ok all good… but “Dave”, I hear you say, “I_’m often working in mobility…. I need something I can use everywhere, perhaps even on my phone_”! Well, it’s your lucky day 😄 Tenth on my list is the mobile support.

With Azure Boards, it's easy to stay on top of changes as they occur!

With the mobile browser and work item form, you gain on-the-go features to stay on top of the latest updates made to work tracking. When you click any work item link on your mobile device, it will open a mobile-friendly version of the work item. From there, you can update the work item or access all work items assigned to you or that you're following.

Reason 11: Start for free

Ok, what more after all we have seen? Well, last (but definitely not for importance) reason for me to use Azure Boards is that… well… you can start absolutely for free! And if your team is up to 5 users.. well, you can keep it for free forever.

Also, anybody in your team with a Visual Studio subscription gains free access to Azure Boards as well. And finally, you can add unlimited stakeholder users to it.

If you want to know more about the stakeholder users in Azure DevOps check out the video I made about this subject.

Conclusions

Alright, those were my 11 reasons to start using Azure Boards. What do you think? Let me know in the comments below if you going to use Azure Boards, or at least you want to give it a try. Also, in case you won’t, let me know why and if there is any feature you think it’s missing from my list.

Also, check out this video, in which I show some of the features of Azure Boards in action

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

GitHub Larger Runners EXPLAINED! - No more limits

Davide 'CoderDave' Benvegnù — Tue, 27 Jun 2023 02:01:02 +0000

Do you want to build your application with GitHub Actions, but the standard agents are not powerful enough for your needs and at the same time you don’t want to use self hosted runners?

Well, GitHub has just released the Larger Runners feature and it is exactly what you need.

Let’s take a look at it.

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation and demo, which to be fair is much more complete than this post.

Link to the video: https://youtu.be/lTAkB7P1qV0

If you rather prefer reading, well... let's just continue :)

About Action Runners

As I’ve mentioned in the intro, today we are going to take a look at the GitHub Larger Runners. We will see them in action (no pun intended) in a moment, but I think is important to have a bit of context around GitHub Actions runner first. Feel free to skip to the the next part if you know already everything about GitHub Actions.

First of all, runners are basically the machines that execute jobs in a GitHub Actions workflow.

For example, a runner can clone your repository locally, install testing software, and then run commands that evaluate your code.

GitHub provides runners that they maintain and you can use to run your jobs. Each GitHub-hosted runner is a new virtual machine hosted by GitHub with the runner application and other tools preinstalled, and is available with Ubuntu Linux, Windows, or macOS.

When you use a GitHub-hosted runner, machine maintenance and upgrades are taken care of for you.

Until now they only had a single size of these runners, with 2 cores and 7Gb of ram for the windows and linux runners, and 3 cores and 14gb of ram for MacOs.

And this meant that if your application needed more resources to be built or tested, you had to install your own runners, on your own hardware or cloud of choice. While this is not necessarily a huge problem, it comes with 2 downsides:

First, you need to take care of the installation and upgrade of all the needed tools and libraries yourself,
and second your own hosted runners are not ephemeral, meaning that all the files, temporary folders, etc from the previous completed jobs are still on the machine.

And this is where the new GitHub Larger runners come into play.

The Larger Runners

We now have the option of allocating a lot more resources to our runners, up to 64 cores and 256 gb of ram, while having them still hosted and managed by GitHub directly! Which means tools installation, maintenance, etc, are all already done. And, the runners are ephemeral.

There are a couple of other somewhat minor differences between standard hosted runners and larger runners, you can check them out all here on the official documentation.

Create Larger Runners

So, how can we enable and use the Larger Runners?

Check the demo section of the video to see this in action

From your organization home page, go to Settings, scroll down to Actions, and click on Runners. Here you have the list of runners already associated to your org.

Next, click on the New Runner button, and pick New GitHub-hoster runner.

This takes you to the creation page.

You can give it a name, select Ubuntu Linux or Windows Server as OS (MacOS will be available soon), and select the size: from 4 cores 16gb of ram all the way to 64 cores and 256gb of ram.

You can set a maximum concurrency, which means how many runners can be createad and run at the same time.

And, if you are on GitHub Enterprise, you can even assign a unique static public IP range for these runners.

Click Create Runner and you are done.

Use Larger Runners

Check the demo section of the video to see this in action

The creation was super easy, but how to use the new runners? It’s no different on how you normally use any other runner.

Just edit your workflow YAML file and in the runs-on field use the name of the runner you have created.

In my case, using "a lot of imagination" I called it mynewrunner so that is what I am going to use.

From now on, my workflow will use the new larger runner. Not difficult, right?

Pricing and Availability

Another important thing is pricing.

Compared to standard GitHub-hosted runners, larger runners are billed differently. Larger runners are only billed at the per-minute rate for the amount of time workflows are executed on them. There is no cost associated with creating a larger runner that is not being used by a workflow.

Also, larger runners are not eligible for the use of entitlement minutes on private repositories. For both private and public repositories, when larger runners are in use, they will always be billed at the per-minute rate.

Last but not least, availability. Larger runners are available for organizations and enterprises using the GitHub Team or GitHub Enterprise Cloud plans.

Conclusions

Let me know in the comments below what you think about the Larger runners, if you are using or going to use them, and for what specific application or requirement.

Also, check out this video in which I cover all the automation capabilities of GitHub Actions.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

5 Top Reasons to Use GitHub Actions for Your Next Project

Davide 'CoderDave' Benvegnù — Wed, 22 Mar 2023 01:24:25 +0000

A lot of people have been asking me on Twitter, Discord, Facebook, etc, whether they should be using GitHub Actions and why choosing it over other services. So I’ve decided to put together 5 of the most important reasons why I think GitHub Actions is a great service.

Video

As usual, if you are a visual learner, or simply prefer to watch and listen instead of reading, here you have the video with the whole explanation,:

Link to the video: https://youtu.be/vNb-NAogQUc

If you rather prefer reading, well... let's just continue :)

Automation

Anyway, why use GitHub Actions? Well, first reason is Automation.

GitHub Actions can automate your workflow, allowing you to build, test, and deploy your code right from GitHub. This can save you a lot of time and effort. For example, you can use GitHub Actions to automatically build and test your code every time you push a commit to GitHub. This ensures that your code is always up-to-date and working as expected.

But it doesn’t stop here. As you may have heard me saying already, you can also use GitHub Actions to automate other tasks, such as sending notifications, running scripts, managing pull requests and issues, and much more.

I have a whole video about automating stuff with Actions, you have the link up here and in the video description.

Customization

Second reason to use the service is Customization.

GitHub Actions are highly customizable. You can create your own actions or use actions from the GitHub Marketplace to build workflows that meet your specific needs. For example, you can use a pre-built action to deploy your code to a specific cloud provider.

Or you can create your own action to run a custom test suite. You can also use environment variables and secrets to customize your workflows even further. If you can think about it, you can do it. There is no limit with GitHub Actions!

Oh btw, let me know in the comments if you want me to cover the creation of custom actions in a future article/video.

Integration

Another reason to use GitHub Actions, the third one, is Integration.

GitHub Actions integrates seamlessly with other GitHub features, such as pull requests and issues. This makes it easy to manage your entire workflow in one place. For example, you can use GitHub Actions to automatically build and test your code whenever a pull request is opened.

This ensures that your code is always tested before it’s merged into your main branch. You can also use GitHub Actions to automatically close issues or assign them to specific team members.

Furthermore, Actions integrate with the major cloud providers, including Azure, AWS and GCP, and most of the common DevOps and work management tools like Jira, Service Now, Slack, etc, and you can use it even if your code is not in GitHub (like if you are using, for example, GitLab, Azure DevOps, Jenkins, etc)

Community

Fourth reason to use GitHub Action? The Community.

GitHub Actions has a large and active community. And this is a double advantage.

You can find many pre-built actions in the GitHub Marketplace, and you can also share your own actions with the community. This makes it easy to find and use actions that meet your specific needs. You can also contribute to the community by creating your own actions or improving existing ones.

As I’ve mentioned there is a second advantage to the large community behind GitHub Actions: the support. You can literally find thousands and thousands of people who have either experienced already your pain points and challenges, and so you have the solutions arleady ready, or you can ask in forums like Stack Overflow or GitHub’s own portal “GitHub Community” and have the answers to your questions in literally minutes.

Cost

And if you need one more reason to use GitHub Actions, the fifth and last one of this video, that would be Cost. Or, better, lack thereof*.*

GitHub Actions, in fact, is free for public repositories, and you get 2,000 free minutes of build time per month for private repositories. This makes it an affordable option for developers of all sizes. If you need more build time, you can purchase additional minutes at a reasonable price. You can also use self-hosted runners to run your workflows on your own infrastructure.

Conclusions

Let me know in the comments if you have other important reasons why you think someone should use GitHub Actions and, if you want to know more about the service, check out my complete 1 and a half our GitHub Actions course.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

I Let A.I. Do DevOps - This Is What Happened (feat ChatGPT and DALL-E)

Davide 'CoderDave' Benvegnù — Tue, 03 Jan 2023 03:40:30 +0000

What happens when AI does DevOps? Is it reliable? And does it make any sense at all?

I've asked AI about DevOps, and today we will discover what it said...

Intro

I’m sure you have probably heard of ChatGPT, the new AI bot from OpenAI. This technology is somewhat mature, even tho it’s technically still a research preview, and I’ve seen it used in multiple different ways, even for YouTube videos. The problem is that the results are not always very good.

For example, Kile Hill has used AI to create a video about Black Holes… and yeah, that didn’t make any sense whatsoever.

On another video tho, Linus from LTT asked ChatGPT to help him choose the component for a PC and actually assemble it, and the result was brilliant.

So today I decided to try it out for myself and have AI telling me about DevOps.

I have asked A.I. the following 4 questions:

Explain DevOps in simple terms
How to do DevOps?
Is DevOps beneficial for any company size?
What is the best way to start with DevOps?

Video

I've also generated some "DevOps-related" images using OpenAI’s DALL-E service. If you want to see those AI-generated images side-by-side with the AI DevOps, or simply prefer to watch and listen instead of reading, here you have the video with the whole text an images.

Link to the video: https://youtu.be/oic6yQL8myc

If you rather prefer reading, well... let's just continue :)

DevOps by A.I.

What follows is what ChatGPT created for me, word by word.

DevOps is a software development approach that emphasizes collaboration and communication between developers and operations staff. The goal of DevOps is to improve the speed and quality of software delivery by automating processes, integrating testing and deployment, and fostering a culture of continuous improvement.

One of the key principles of DevOps is "infrastructure as code," which means that instead of manually configuring and managing servers and other infrastructure components, teams use code and automated tools to define and manage these resources. This enables them to rapidly provision, scale, and update their infrastructure in a consistent and repeatable way.

Another important aspect of DevOps is the use of agile methodologies, which focus on iterative, incremental development and the ability to quickly respond to change. This allows teams to deliver new features and updates to customers more quickly and efficiently.

Overall, DevOps aims to improve the collaboration and communication between different teams in an organization, and to streamline and automate the software delivery process.

There are many ways to practice DevOps, and the specific approaches and tools that a team uses will depend on their specific needs and goals. However, here are some general steps that teams can follow to adopt a DevOps approach:

Establish a culture of collaboration and continuous improvement: One of the key foundations of DevOps is a culture of collaboration and continuous improvement. This means fostering a mindset of shared responsibility and openness to change across all teams, and encouraging regular communication and feedback.
Automate and standardize processes: Automating and standardizing processes can help teams reduce errors, improve efficiency, and ensure consistent results. This can include automating tasks such as testing, deployment, and infrastructure management.
Use agile methodologies: Agile methodologies, such as Scrum and Kanban, emphasize iterative, incremental development and the ability to quickly respond to change. Adopting agile practices can help teams deliver new features and updates more quickly and efficiently.
Implement continuous integration and delivery: Continuous integration and delivery (CI/CD) involves automatically building, testing, and deploying code changes as they are made. This can help teams release new features and updates more quickly and safely.
Monitor and measure: Monitoring and measuring the performance of systems and processes can help teams identify and fix issues, and track progress towards goals. This can include using tools such as monitoring, logging, and analytics platforms to gather and analyze data.

By following these steps, teams can adopt a DevOps approach and improve the speed and quality of their software delivery. It's important to note that DevOps is not a one-time implementation, but rather a continuous process of improvement and evolution.

DevOps can be beneficial for companies of any size, although the specific benefits and the ways in which DevOps is implemented may vary depending on the size and complexity of the organization.

For smaller companies, DevOps can help improve the speed and efficiency of software delivery, allowing them to bring new products and features to market more quickly and respond to customer needs more effectively. DevOps can also help smaller companies reduce the risk of errors and outages, and improve the reliability and performance of their systems.

For larger companies, DevOps can help streamline and automate complex processes, improving the efficiency and effectiveness of software delivery at scale. DevOps can also help large organizations reduce the risk of errors and outages, and improve the reliability and performance of their systems.

Overall, DevOps can be beneficial for companies of any size by improving the speed and quality of software delivery, reducing the risk of errors and outages, and improving the reliability and performance of systems. However, it's important to carefully consider the specific needs and goals of the organization and plan an implementation strategy that is appropriate for the company's size and complexity.

If you are looking to start with DevOps, here are some general steps that you can follow:

Establish a clear understanding of the goals and benefits of DevOps: Before starting to implement DevOps, it's important to have a clear understanding of what you hope to achieve and how DevOps can help. This may involve identifying specific pain points or challenges that DevOps can address, as well as the broader benefits that you hope to achieve.
Build a cross-functional team: DevOps relies on close collaboration and communication between different teams, so it's important to bring together a diverse group of individuals from different departments and functions. This team should include developers, operations staff, and any other relevant stakeholders.
Identify and prioritize areas for improvement: Once you have established a team, you can begin identifying and prioritizing areas for improvement. This may involve analyzing current processes and identifying bottlenecks or inefficiencies, as well as defining specific goals and metrics for measuring progress.
Choose tools and technologies: There are many tools and technologies available to support DevOps, and the specific ones that you choose will depend on your specific needs and goals. It's important to carefully evaluate different options and choose tools that will support your goals and workflows.
Establish a culture of continuous improvement: Building a culture of continuous improvement is key to the success of DevOps. This means fostering a mindset of shared responsibility and openness to change across all teams, and encouraging regular communication and feedback.

By following these steps, you can start to implement DevOps in your organization and begin reaping the benefits of improved collaboration and efficiency. It's important to remember that DevOps is not a one-time implementation, but rather a continuous process of improvement and evolution.

Conclusions

Alright so… as mentioned that was all AI generated. Let me know in the comments below what you think about it. It was not too bad, was it? Actually fairly accurate… few strange things here and there but I’d say not bad.

The images on the other side… well, let’s say the result is questionable… they didn’t make much sense, and especially the writings on them was on a completely unreadable fake language… nice try OpenAI, nice try…

Check the video if you want to see the AI-generated images about DevOps

Anyway, that’s all I have for you today. But before going, check out this video over here, in which I talk about what, for me, are the real benefits of doing DevOps 🙂

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

A Centralized Control Center for Azure DevOps!

Davide 'CoderDave' Benvegnù — Wed, 07 Sep 2022 02:00:25 +0000

Enable Observability at Organization Level for Azure DevOps

Discover how to create a centralized dashboard for managing Azure DevOps in your organization. Always wanted to have a central control center that allows you to see the status of all your projects in your Azure DevOps organization?

In this Live with Vinicius Moura (DevOps MVP) we see how to achieve exactly that! For FREE!

Link to the video: https://youtu.be/VkoZLw56bhw

If you want to know more, post your questions down below so I can address them.

Thanks so very much again for your support!

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

Create a New GitHub Repo in 1 CLICK from VSCode

Davide 'CoderDave' Benvegnù — Tue, 16 Aug 2022 06:00:00 +0000

Do you have some code in VSCode and want to take it to GitHub, without having to write a single command in the CLI? Today I’m gonna show you how to do that, how to publish your code to a new GitHub repo, all from VSCode.

Introduction

I already have an article and a video talking about how to use VSCode with GitHub, but, as someone has pointed out:

That content assumed you already had your code on GitHub. But what if you don’t? Let’s do it now.

Video

Link to the video: https://youtu.be/shP-3p-2m6g

If you rather prefer reading, well... let's just continue :)

Just one prerequisite

Everything you need to create a new repository in GitHub from VSCode is already present in Visual Studio Code itself. The only thing you need to make sure to do before hand is logging in into VSCode with your GitHub user.

Your VSCode should look like this:

Of course with your username, not mine 😇

If it is not like this, click on Sign In (GitHub) and you are good to go.

Create the repo

Now that we know we are logged in, creating the repository in GitHub is very easy.

Just click on the Git - Source Control icon

And this will prompt you to either Initialize Repository or Publish to GitHub

The first option does only execute the git init command, so it does technically create a repository for you but only on the local machine. If you want to have your repo in GitHub, instead, use Publish to GitHub. This will do for you the repo initialization as well, but will also create a new repo in GitHub and push the code to it.

When you click on Publish to GitHub, VSCode will ask you what name you want your new repo to have (defaults to the name of the root folder of your project) and you can choose whether you want your new repo to be private or public.

Last thing you can do is select what files or folders you want to include in your repo (the default is everything, so if that's what you want to do you can just skip this step).

And after that, VSCode will do its magic, create the repo for you in GitHub, set it as the origin on the local folder, and push the code.

Conclusions

Cool right? And you know what would be even cooler? If you could hit the like buttons on the side :)

Jokes aside, now that your code is on GitHub, go and check this other video I’ve mentioned before to see how you can manage it directly from VSCode as well.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

Ask Me Anything: DevOps, GitHub and Azure DevOps (10k subs special LIVE)

Davide 'CoderDave' Benvegnù — Mon, 01 Aug 2022 04:32:31 +0000

Got any questions about DevOps, GitHub and/or Azure DevOps?

Join me for this live Q&A and I will try and answer all your questions!

And we will celebrate the incredible achievement of 10,000 subscribers on YouTube

Link to the video: https://youtu.be/44PoWwStc7s

Prepare your questions, and I hope to see y'all live! And if you can't make it, post your questions down below so I can address them during the live!

Thanks so very much again for your support!

⏲️ TIME FOR THE LIVE:

Wednesday, August 3rd, 9.30 pm HKT
Wednesday, August 3rd, 7.00 pm IST
Wednesday, August 3rd, 1.30 pm UTC
Wednesday, August 3rd, 9.30 am ET
Wednesday, August 3rd, 6.30 am PT

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

Protect and Access you Kubernetes, Servers, Applications and Databases with Teleport

Davide 'CoderDave' Benvegnù — Tue, 14 Jun 2022 04:46:20 +0000

Today we are protecting and securely connecting to our infrastructure, Kubernetes, and basically any other private resources that we need and want to keep safe.

And we will do so without the need of VPNs or legacy access management systems... and for free, thanks to Teleport.

Intro

Finding a tool that allows you to securely access the infrastructure you need without slowing you down is already a challenge in and of itself. But finding a single tool which provides unified access to Linux and Windows servers, Kubernetes clusters, databases and DevOps applications like CI/CD, version control, and monitoring dashboards across all environments is almost impossible. Almost, because we have Teleport for it.

Check out Teleport here: https://geni.us/teleport

Video

In this video I’m going to show you what we can do with Teleport, and how easy it is to use it to connect to your protected resources, rather than how to install it, also because the documentation does an excellent job on guiding you step-by-step. But let me know in the comments if you wanna see the installation process as well in another video.

Here you have the video with the whole explanation.

Enjoy the watch :)

Link to the video: https://youtu.be/062Rv1eWKEY

📼 Video Main Sections

Conclusions

I think you now understand why I’ve decided to make this video about Teleport. I really think it is a great service that allows you to do a lot of things... What we have seen are just few examples, but I hope you can see the full potential of this service.

If I have to nitpick, I would like for the installation process for Windows hosts to be a little simpler and more intuitive, it’s the only one that gave me a little trouble. Also, as we have seen some AWS and GCP services are supported out of the box, like the Linux servers and DBs. Being a heavy Azure user as y’all know, I would love to see Azure supported natively as well.

Let me know in the comments below what you think about Teleport, and if you want to see more use cases, or if you want to know how Teleport works behind the scenes, or yet, as I’ve mentioned before, if you want me to make a video about the installation of this service on the different platforms.

Also, check out this video, in which I talk about Pros and Cons of the emerging Civo Kubernetes Cloud.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

Top DevOps Announcement from Microsoft Build 2022

Davide 'CoderDave' Benvegnù — Fri, 27 May 2022 09:48:18 +0000

Microsoft Build 2022 has just closed its virtual doors, with a lot of new services and features, and this time around a lot has been said also about DevOps.

Today I’m going to recap all the most important announcements around DevOps made by Microsoft at Build 2002

Video

Link to the video: https://youtu.be/Lq0BPwa69C8

If you rather prefer reading, well... let's just continue :)

The Great Absent

Let’s start not with an announcement but rather with a lack thereof, with the great absent at Build 2022: I’m talking about Azure DevOps.

There were in fact a lot of announcements and sessions revolving around GitHub, and that’s to be expected, but not a single session, announcement, feature or demo in which Azure DevOps has been shown or even mentioned.

I think this is a clear sign for us on what the future for Azure DevOps looks like, but stay tuned because I will have a great guest on my YouTube channel very soon and we will talk exactly about this.

Fully Managed NGNIX on Azure

Talking about stuff that was actually present at Build 2022, let’s start with one of my favorite announcements: Azure now has a fully managed nginx offering.

NGINX for Azure, which is currently in preview, is a SaaS solution with advanced traffic management and monitoring. The tight Azure integration enables ease of use with a few clicks for provisioning and configuration though the Azure portal.

The service offers advanced traffic management features, such as JSON Web Token (JWT) authentication and active health checks, and built-in security integrations like Azure Key Vault for SSL/TLS certificate management.

NGINX for Azure is offered by Microsoft in partnership with F5, so you can find it through the Azure Marketplace, but you get a unified bill for all services they use on Azure and leverage existing enterprise agreements.

And the great thing is that being an Azure service, you can manage all the aspects of it via the Azure portal, including making configurations changes that are then applied to the service directly, and using config files that you may already have from previous deployments.

And last but not least, they have developed a GitHub integration that allows you to version control your configuration in a GitHub repo and to apply changes to that configuration via GitHub Actions

Microsoft Dev Boxes

We will talk again about containers in a minute, but let me change page and talk about another announcement I quite liked. I’m talking about Microsoft Dev Boxes.

Microsoft Dev Boxes, currently in private preview, is a new cloud service that provides developers with secure, ready-to-code developer workstations. This service basically makes it easy for developers to access the tools and resources they need without worrying about workstation configuration and maintenance.

If it sounds like what GitHub Codespaces does is because, in a way, the two services have the same purpose: make development easier and management of dependencies quicker.

Dev Boxes, however, goes a step further than Codespaces, because it supports all kinds of development, including desktop and mobile, and it runs on Windows 11 (while codespaces run only on linux). And in fact you can use it from the browser but also using Remote Desktop.

Dev teams preconfigure Dev Boxes for specific projects and tasks, enabling devs to get started quickly with an environment that’s ready to build and run their app in minutes. At the same time, Microsoft Dev Box ensures unified management, security, and compliance stay in the hands of IT by leveraging Windows 365 to integrate Dev Boxes with Intune and Microsoft Endpoint Manager.

Azure Deployment Environments

And when you are ready to test your applications or run them against other services, Azure Deployment Environments, also in private preview, will make it easy for developer teams to quickly spin up app infrastructure with self-service of project-based infrastructure-as-code templates.

This will minimize set-up time while maximizing security, compliance, and cost efficiency, and enforcing best practices

Azure Load Testing

Let’s move now to the next new service, Azure Load Testing.

Few years ago, Microsoft had their own Load Testing service integrated in Azure DevOps… actually, at that time it was still called Visual Studio Team Services. But that service has been deprecated for years already, leaving Microsoft and Azure without a proper Load Testing service… well no more.

Azure Load Testing is a fully managed load-testing service built for and in Azure that makes it easy to generate huge load using Azure resources and identify app performance bottlenecks.

It enables developers and testers to generate high-scale load and run simulations that reveal actionable insights into app performance, scalability, and capacity.

The service can use existing Apache JMeter scripts, and you will get recommendations backed by metrics and analytics.

Azure Load Testing also supports continuous integration and continuous delivery (CI/CD) workflows to give continuous feedback.

I’m really excited to try this service out, stay tuned because I will for sure have a video in which I’m going to test it and review it.

Azure Container Apps GA

Alright, next up the GA of Azure Container Apps. The service has been in preview for a while, but now it has reached GA which means that it’s stable for production workloads.

Azure Container Apps allows you to run your containerized apps in a serverless manner, but still taking advantages of Kubernetes, Keda for event-driven autoscaling, dapr, and Envoy.

And all of this is fully managed by Microsoft so you can just focus on the application and not on managing infrastructure

One of the cool features of this service is that you can scale your pods down to 0 instances and spin up more pods automatically if requests come in.

And if all of this was not enough, during the event Scott Guthrie showed a demo in which with a single command of the Azure CLI he was able to have an application containerized, a container registry create in Azure, some GitHub Actions workflows created and run to build the image of the application, and finally have everything deployed to Azure in a brand new Azure Container App.

Draft v2 Integration

And if you are curious about how the app is getting containerized, this is thanks to another new announcement made at Build 2022. I’m talking about the public preview of the support for Draft v2.

Draft is an open-source project that streamlines Kubernetes development by taking a non-containerized application and generating the Dockerfiles, Kubernetes manifests, Helm charts, Kustomize configurations, and other artifacts associated with a containerized application. Draft can also create a GitHub Action workflow file to quickly build and deploy applications onto any Kubernetes cluster.

With the public preview just announced, Draft is now integrated with AKS through the Azure CLI, Azure Portal, and Visual Studio Code. And works with Azure Container Apps as well, as we have seen.

AKS Web App Routing

And still talking about containers and AKS, there is another interesting feature that has been announced at Build: the preview for Web App Routing.

I couldn’t find much about this new AKS add-on, and also the part of the session where the announcement has been made was quite short, but what we know from the official website is that

Web app routing helps you get your web application up and running in AKS securely while removing the complexity of ingress controller, certificate, and DNS management, and that the service offers a managed ingress controller powered by NGINX that you can use without restrictions and integrates out of the box with open service mesh to secure intra-cluster communications.

I’m curious to see this in action, let me know in the comments if you have already tried this out.

Fully Managed Grafana

Next and final announcement that I’m going to cover today is another big one for me. Microsoft announced the public preview of a fully managed Grafana service in Azure.

As I’ve mentioned, Azure Managed Grafana is a fully managed service for analytics and monitoring solutions. And it's supported by Grafana Enterprise, which provides extensible data visualizations.

You can provision the new Azure Managed Grafana and connect it to your AKS cluster, and with that you can see all the metrics and data provided by container insights, visualized in the familiar interface of Grafana. You can see information like requests per second, the resources that you're using for your pods, and all of the different things you need to run your application successfully.

And since Grafana is an open-source product, it's available to you in Azure or wherever you want to run it.

And yes, that dashboard you see above is automatically created when you provision Azure Managed Grafana and point it to AKS because the service is optimized for Azure-native data sources from services such as Azure Monitor and Azure Data Explorer.

Conclusions

These were for me the most exciting announcements around DevOps at Build 2022, but Microsoft made a lot more announcements so I’d recommend you to check the Book of News that they published to see them all. You can find the link in the video description.

Let me know in the comments below what do you think about the services and new features I’ve covered and what your favorite announcement from Build 2022 was.

Also, check out this video here in which I review a new way to connect to private resources without VPN.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast

Azure Artifacts vs Build Artifacts vs Pipeline Artifacts: Difference EXPLAINED!

Davide 'CoderDave' Benvegnù — Tue, 10 May 2022 08:40:51 +0000

What are the differences between Build Artifacts and Pipelines Artifacts in Azure Pipelines, and how do they compare to Azure Artifact?

With Azure DevOps using similar names for different things, there is quite some confusion between them. And in fact I’ve received many comments and questions about them on my videos about Azure Pipelines... but today we are going to answer these questions once and for all. Let’s dive into it.

Video

Link to the video: https://youtu.be/WWCmEUCt3Cc

If you rather prefer reading, well... let's just continue :)

A Word About Artifacts

So, what are the differences? We will go through them one by one, see what they are used for, and at the end we’ll have a quick recap and some recommendations on what to use when. But first, we need to understand what an artifact is, at least in the context of Azure DevOps.

Using a simplification, an artifact is any kind of file or files that your build produces, or that you may want to reuse in another build, another job of your build, or a deployment or release pipeline.

For example, the compiled DLLs that you have as result of your CI can be stored in an artifact to be then deployed by another job. Same thing for the dist folder of a Node.js application. Or, let’s suppose you want to save some output of one of your pipeline task to then download it and review it later... well, you can package that in an artifact as well.

Now that we know what artifacts are, let’s see how they differ.

Build Artifacts

Build Artifacts have been in Azure DevOps for a long time and are the built-in artifact storage mechanism for Azure Pipelines.

They can be used in both the Classic Build Pipelines, the one created using the UI, as well as the newer YAML Pipelines.

Build Artifacts are published via the Publish Build Artifacts task and can be downloaded with the Download Build Artifact task. And when you publish them, you can instruct the task to either push the content up to the Azure DevOps cloud or serve, or to copy the files to a local file share instead.

Build Artifacts can be consumed from other jobs in the same Pipeline, and from other Pipelines.

Additionally, Build Pipelines can be used if you want to consume your artifact from a Release Pipeline triggered by the build completion.

And you can always download your artifacts from the Build run status page.

And as you can see in the image above, you can explore the content of your artifact directly in the UI.

Pipeline Artifacts

Alright, let’s talk about Pipelines Artifacts now.

These are the newer version, if you will, of Build Artifacts, and as such they can be used only from within the YAML Pipelines.

One of the main benefits of Pipeline Artifacts is that they can dramatically reduce the time it takes to upload and download the artifacts because of the way the files are both uploaded and stored. And this is especially true for large artifacts.

Until fairly recently, Pipelines Artifacts couldn’t be used in Classic Release Pipelines, or from other Pipelines, but now that limitation is gone so their usage is very similar to Build Artifacts.

To publish the Pipelines Artifacts you can use the Publish Pipeline Artifact task and you can download them using the Download Pipeline Artifact task.

Alternatively, since this feature is only available in the YAML Pipelines, you can use the publish keyword and the download keyword, which are just the abbreviation for the whole tasks.

And if you publish a Pipeline Artifacts, and you want to use it in a deployment job in the same pipeline, you don’t even have to add the download task because Azure Pipelines will download them automatically.

Build vs Pipeline Artifacts

There are few more differences in publishing and downloading the artifacts between Build and Pipeline Artifacts.

The publish tasks are virtually identical, with the only differences being that in the Publish Build Artifact task here on the left you can optionally choose to further include your artifact in a Tar file, while this is not present on the right on the Publish Pipeline Artifact Task. This one, instead, allows you to add some custom properties to the artifact. They must be in JSON format, all keys having the prefix user-

It gets more interesting if we look at the Download tasks

As you can see in this side by side view, when you download a a Build Artifact (on the left) you can choose if you want to download the whole thing, or just some specific file from the artifact. You can also set some parallelization settings and other parameters. When downloading a Pipeline Artifact, instead, you don’t have that option, as you can see here on the right hand side of the image.

And if we switch the task to download from a different pipeline or run, instead of from the current one, we have one more difference.

Aside from a different positioning of the fields, you can see that when you download a Pipeline Artifact you can choose to do so even if the pipeline run you are targeting has failed

And that basically covers everything there is to say about Build and Pipeline Artifacts. If you have noticed, I kept comparing the two... but I haven’t mentioned Azure Artifacts yet. Why? Well, because it is a completely different thing.

What About Azure Artifacts?

So Azure Artifacts... as I was saying it is pretty different from Build and Pipeline Artifacts. Despite the similar name, it’s a different service which serves a different purpose.

Both Build and Pipeline Artifacts are very generic, you can save whatever you want in them, and what Azure DevOps does is just packaging the files in a zip archive and saving it somewhere. Azure Artifacts, instead, is a typed package repository.

It supports multiple package types such as NuGet, npm, Python, Maven, and Universal Packages... you can basically see it as an alternative to Artifactory, Nexus, GitHub Packages, and services like that.

You may have seen that Azure Artifacts also supports Universal Packages, and although that is somewhat similar to the other types of artifact we have seen before, it is conceptually different.

You would use Universal Packages when you want to create an artifact with a lifetime independent of the pipeline that created it. In fact both Build and Pipeline Artifacts are always tied to the Pipelines that created them. As we have seen, you can download Pipeline Artifacts after a pipeline has completed via the artifacts UI - but if you want something that really exists independent of pipeline you would go for Universal Packages.

Another big difference is about the pricing. Whether you use Build Artifacts or Pipeline Artifacts, you will not have to pay a single cent for them, no matter how many files you store or how big they are. Azure Artifacts, on the other hand, is billed by size.

You have a free grant of 2 Gb for each organization, but once you reach the maximum storage limit, you can no longer upload new artifacts and will need to either delete some of your existing artifacts, or set up billing to increase your storage limit.

So, let’s recap and see my recommendations.

Build Artifacts are the older type of artifacts and can be used in both Classic and YAML Pipelines. They are fairly slow to upload and download, they are tied to a specific Pipeline run and they can be used to trigger a deployment, via Release Pipelines.

Finally, Build Artifacts cannot be shared, you can use them for storing anything you want, and you don’t pay for the space you use.

Pipeline Artifacts, on the other hand, are newer and faster, but they can be used only in YAML Pipelines. They are also tied to a specific Pipeline run, they trigger CD in both Multistage Pipelines and Release Pipelines, and cannot be shared. Likewise, they can be used to store anything and they are free.

Finally, Azure Artifact is a completely different service. Packages stored in Azure Artifacts can be used in both Classic and YAML Pipeline, and their upload and download are as fast as with Pipelines Artifacts because they share the same underlying technology.

Being a different service, Azure Artifacts are independent from the Pipelines which have publish them, but like the other types can be used to trigger CD.

Finally, they are the only type of artifact that can be shared with developers even cross-organization, but they can be only typed packages and, last but not least, you get 2gb of space for free but after that it’s a paid service.

Recommendations

How would I recommend you use the different types of artifacts?

Use Build Artifacts only if you are using Classic Build Pipelines. There is really no other reason to use them, since they are the older and slower flavor of artifacts.

Use Pipelines Artifacts if you are on YAML Pipelines, and you don’t need to share the result of your CI with other teams.

Finally, Azure Artifacts enables developers to share their code efficiently and manage all their packages from one place. Use Azure Artifacts if you need to share packages within the same team, across organizations, or even publicly.

Conclusions

Let me know in the comments below if you still have any more questions about Build Artifacts, Pipeline Artifacts, and Azure Artifacts and I will try my best to answer them.

Also, check out this video with all you need to know about the differences between Classic Pipelines and YAML Pipelines.

Like, share and follow me 🚀 for more content:

📽 YouTube
☕ Buy me a coffee
💖 Patreon
📧 Newsletter
🌐 CoderDave.io Website
👕 Merch
👦🏻 Facebook page
🐱‍💻 GitHub
👲🏻 Twitter
👴🏻 LinkedIn
🔉 Podcast