DevOps is a modern application development and delivery approach that helps organisations to release quality software more quickly into production with less defects! Though DevOps itself is not a product, implementing its practices requires services and tools. Microsoft offers two widely used platforms for implementing DevOps practices – the Azure DevOps platform and the GitHub platform.  

Adopting a DevOps approach does not yield benefits in isolation, but rather in conjunction with other concepts such as Agile planning and Cloud computing. By utilising platforms such as GitHub for implementing DevOps practices and Azure for cloud services, organisations can achieve a continuous “Code to Cloud” process. This process emphasizes the use of modern CICD platforms to streamline software development for applications running on cloud-based infrastructure and services, including cloud-managed container orchestration platforms and serverless computing services, instead of relying on traditional on-premises servers and infrastructure. 

Supply chain attacks 

As organisations embrace this approach, security teams are faced with new challenges due to the increased velocity, automation, and decentralisation of the development process. Attackers are increasingly targeting organisations through their software development processes. This is where software supply chain security becomes crucial! The software supply chain encompasses everything necessary to create and deliver software, including IDEs, source control systems, build systems, deployment systems, CICD platforms, runtime environments, and various artifacts such as application code, open-source dependencies, infrastructure code, and deployment artifacts. 

Securing the software supply chain is not an easy task and requires a comprehensive and thorough approach. Figure 1 divides the GitHub to Azure code-to-cloud pipeline into five stages.  

NOTE: GitHub offers multiple product options, but this article will centre on GitHub Enterprise which offers some capabilities that are not available in the other options. Specifically, I will emphasize security areas that I consider crucial but may be overlooked. 

Securing the DEVELOPMENT stage 

The development stage is where the code is created, and the first step towards securing this stage is to ensure that developers are using a secure environment for development. A significant concern is the possibility of a compromised development environment resulting from the use of unpatched IDEs or the installation of vulnerable or malicious extensions. IDEs, like any other application, can contain vulnerabilities and require regular updates to ensure their security. A recent example is CVE-2022-41034, a critical vulnerability disclosed for Visual Studio Code that allows for remote code execution on any system with the IDE installed.  

Using a managed development environment like GitHub Codespaces provides the advantage of quickly applying necessary patches to ensure the environment’s security. In addition to this, each Codespaces environment runs on its own freshly built isolated virtual machine and network with a firewall used to block incoming connections from the internet and internal networks.  

Codespaces also  

Securing the SOURCE CONTROL stage 

The source control stage is where the code is stored, discussed, and managed, and it is essential to ensure that the source code repository is secure. This starts with access controls and permissions. Only authorised individuals should have access to our repositories.  

To access GitHub enterprise services and resources, users need to be authenticated. There are three methods for adding users to our GitHub Enterprise organisation for access (Figure 2).  

The first option is to invite users with their personal GitHub account which enables them to authenticate through GitHub.com and access our organisation resources. With this option, the user maintains control of their identity (since it is their personal account), and can continue to contribute to other enterprises, organisations, and repositories outside of our organisation. 

The second option is to use an external identity provider that supports SAML single sign-on. With this option, users authenticate with an identity in the external SAML provider that is linked to a personal GitHub identity. This means that while users are still utilising a GitHub identity to access our organisation’s resources, the actual authentication takes place through the external identity provider. The identity can be used for contributions to other enterprises, organisations, and repositories outside of our organisation. 

The third option is to use “Enterprise Managed Users“ – EMU which is similar to other single sign-on solutions. With EMU, users will access GitHub organisation resources using a single identity created and managed in the external identity provider. They do not need to have a personal GitHub identity. This gives the most control for enterprise users. 

The recommendation, if you are an enterprise, is to use either the second option or the third option. 

To perform any actions on GitHub, such as creating a pull request in a repository, a person must have sufficient access to the relevant resource. This access is controlled by permissions. A permission is the ability to perform a specific action. For example, the ability to delete an issue is a permission. A role is a set of permissions you can assign to individuals or teams. 

GitHub supports roles at different levels depending on what we are looking to achieve: 

• Organisation-level roles which are sets of permissions that can be assigned to individuals or teams to manage the organisation settings, repositories, teams. 
• Repository-level roles which gives organisation members, outside collaborators and teams of people varying levels of access to repositories. 
• Team-level roles that give permissions to manage a team.  

The recommendation here is to carefully guard and audit assignment of roles like Organisation owners. It is also prudent to be mindful of the base permission set, which affects all members of an organisation who access any of its repositories (except outside collaborators). 

Securing the BUILD stage 

The build stage is where the code is compiled into an executable or deployable artifact, and it is essential to ensure that the build process is secure. Implementing security in this phase involves adding automated security tools like Static application security testing (SAST) tools, software composition analysis (SCA) and unit testing. It is important to test the build output artifacts. 

A key area of concern here is the heavy dependence on open-source libraries, indicating that development teams have transitioned from creating software to assembling it. Veracode’s “state of software security research” analysed the proportion of code included in software and found that 97% of Java applications consist of open-source libraries. The percentage of third-party code in .NET applications was around 60% whereas JavaScript and Python applications were found to contain about 50% of open-source libraries. This approach makes practical sense as it enables teams to provide value to customers more efficiently without duplicating efforts. 

However, using someone else’s code can come with potential risks. By incorporating their code into your application, you’re essentially giving them access to your code repository. It’s important to consider whether you trust the author and contributors of the code you’re using, as well as whether the code could contain flaws or vulnerabilities that may impact your customers or users. This is especially true for transitive dependencies, which make up a significant portion of JavaScript dependencies (over 98% according to GitHub State of the Octoverse report 2021). Even if the code you’re using appears to be secure, the transitive dependencies it relies on could contain vulnerabilities that you’re not aware of. 

GitHub Advanced Security includes features for supply chain security that enable you to scan software dependencies for potential vulnerabilities. Additionally, the GitHub Marketplace provides numerous actions that allow you to seamlessly integrate third-party security platforms, such as Prisma Cloud, into your GitHub workflows. This can help ensure that your code is protected and secure from potential threats. 

Securing the DEPLOY stage 

The deploy stage is where software that has been tested and approved (artifact) is sent to the production environment. This may happen without the need for manual intervention (automatically), and it makes it faster and more efficient to roll-out product changes. Implementing security in this phase involves making sure that the artifacts we are releasing and the environment we are releasing them to are verified, secure and compliant. This includes making sure that the artifacts are stored in a secure and trusted location and having processes in place to validate the integrity of the artifacts against tampering. 

GitHub Packages provides a hosting service for storing and managing software packages. Packages are stored in a secure registry, and access is controlled by the user’s authentication and authorisation credentials. 

Many companies also use infrastructure as code (IaC) to set up their environments prior to deploying new or updated artifacts. However, it’s crucial to ensure that these IaC templates adhere to security guidelines and compliance requirements, particularly with regards to encryption, logging, and secure access. 

According to a study by the Unit42 team, several open-source deployment artifacts were analysed, and the results were concerning. Specifically, the study found that 64% of Terraform modules had at least one high or critical insecure configuration, 99% of Kubernetes Helm charts had misconfigurations, and 91% of container images had at least one critical or high severity vulnerability. These findings highlight the importance of thoroughly assessing and validating IaC templates to ensure that they are secure and compliant before deploying them. The extensibility of GitHub with marketplace extensions makes it easy to integrate open-source tools like Chekov for this use case. 

Securing the RUNTIME stage 

In the runtime stage, the focus is on running and maintaining deployed software in the production environment. Implementing security in this phase involves regularly applying security patches and updates to keep the software and runtime environment up to date; Monitoring for security vulnerabilities or breaches; Implementing security controls such as firewalls and intrusion detection systems; Implementing processes for regularly reviewing and analysing security logs to identify potential threats; Establishing processes for responding to and mitigating security incidents. Azure has an excellent security baseline documentation that I recommend looking into.

The post ​​​Securing the Code to Cloud Pipeline with GitHub and Azure​ appeared first on Microsoft Industry Blogs - United Kingdom.

Load testing is a vital step in the lifecycle of a service – for a team to know that their service can take the load required of it.

Azure Load Test to the rescue

With the advent of Azure Load Testing, almost all of the infrastructural challenges of building load tests have been removed. You just have to be able to write or adapt JMeter JMX files and upload them into a load test. I recommend looking at this tutorial for how to use Azure load testing against a web app.

What is special about background processes?

The use of load testing means it is now quite straightforward to test web apps and APIs, but it is less clear how to effectively load test and monitor a background or asynchronous service and to know when all of the background processing has completed and also that all requests have been processed correctly.

This repository contains an Azure Load Testing sample that tests and monitors an asynchronous service. This is supplied with a sample application against which the load test can be run. This sample application comprises some APIs which push messages to a queue and then later processes these messages from the queue.

How does load testing solve these problems?

This test:

1. Sends a fixed number of POST requests to an API
2. Uses a second phase of the load test to then poll another API to see how many items remain to be processed. Only when there are none, does the test complete.
3. Uses a custom metric in application insights to represent this queue length.

In this way, the load test executes for as long as it takes to process all of the data and the load test can then pull in the custom metric to graph the items remaining to be processed into the load test results. Thus giving the tester a more complete picture of how long an asynchronous process takes to complete a given number of requests.

Load Test Structure

All JMeter load tests use the notion of thread groups. These are blocks of HTTP requests to be sent. Standard load tests start with a low number of threads and ramp up to a fixed number and continue for a given period of time. This style of thread group will send many requests to the target and this will vary depending on how fast the target can keep up with the number of requests.

The thread groups in this test are while loops and can send a fixed number of requests or can keep sending requests until a condition is met. This is useful as the use of these while loops can firstly send a fixed number of requests and secondly run the test until the background queue of requests is empty.

This load test has 2 thread groups:

1. The first group generates the API post calls. This one is designed to send a fixed number of HTTP POST requests. The number is parameterised and can be injected into the test at runtime. This thread group is the minimum needed.
2. The second thread group is designed to poll the state of the number of pending items to complete and in the test application, queries the service bus queue length – but it’s HTTP GET request could query something else, such as a database. This thread group is designed to run after the first thread group (this is not the default JMeter behaviour) and is designed to allow the test to keep running until all requests are processed. That way, the length of the test is the total time to process all messages.

A simpler arrangement could be to just use a single thread group and to let the test complete once all requests are sent. But you would then have to separately look at the metrics of the system under test to establish when the service has completely finished processing. But, the 2 thread groups give a more complete picture.

To allow the load test to get a more complete picture of the remaining items to be processed, the system under test regularly polls the remaining item count and generates a custom metric – this metric can then be pulled into the load test run.

The load test definition JMX file is in this folder here.

It requires three parameters to be set in the Azure Load Test parameters section:

1. The function web app name (without https://)
2. the number of requests to be sent
3. The functions key needed to POST requests to the functions HTTP endpoint. This can be found in the App Keys section of the Azure function.

Demonstration System Under Test

The system under test comprises 4 Azure functions:

1. An HTTP triggered function (web API) that takes a message from the HTTP body (POST) and then pushes this into a service bus queue. This is the load generator for background processing.
2. A service bus queue triggered function that does some processing on the message received and then copies this to Azure blob storage. This is a message processor and the one supplied has been designed to be slow to simulate a some complex background processing. As a side effect, the count of the messages in the blob storage may also be used to verify processing completeness.
3. An HTTP triggered function (web API) that returns a count of the number of messages in the service bus queue. This API is used by the second phase of the load test to poll the number of items in the service bus queue. The load test looks for zero items to complete the execution of the load test.
4. A timer triggered function that continuously checks the number of items in the service bus queue (every 15 seconds by default). It then sets this as a value in an Application Insights custom metric. This continuously triggered function is responsible for providing the metric that the load test can pull from application insights to give the “burn-down chart” for the test.

All of the above functions are built into a single function app for a single deployment. These have a number of application settings that are discussed in a later setting.

To be clear, this is a demonstration application, but it allows you to test the load test before using it on a real target service. But elements of this could be added to an existing service to support this form of testing.

Custom metric

As can be seen from above, the first phase of the test rapidly increases the number of items to be processed. Once these have been sent, the background processes start working away. The slope is more shallow as it is taking longer to process each message than it did to create. In a production system, attempts should be made to optimise this background processing. Also Azure Functions when triggered on Service Bus queue also scale out to more instances – thus doing more work in parallel. The scale limit of the funtion app can be changed to tune this. See below:

Load Test Sample Run

As can be seen above, this is the report from the load test:

1. The load test total time is the time it takes to consume and process all of the background messages
2. The total number of requests is a combination of the fixed POST requests to create the messages plus the polling to wait for the test to complete.
3. The custom metric is shown in the repot and shows the burndown of message processing

Deploying the sample application

So far there is not a deployment script, but this needs:

1. A function application
2. Service bus namespace and queue
3. Application Insights (this may be created at the functions app deployment, but it does need to be associated with the function app)
4. Storage account
5. Load Testing instance

Deployment Steps:

1. Deploy the infrastructure above
2. Git clone the application and build in Visual Studio
3. Using the deployment profile publish the application (functions) to the Azure function app
4. Set all of the configuration items for the function. See next section
5. Create the load test, using the JMX file provides
6. Set the load test parameters

Function App Configuration Items needed

1. ServiceBusConnection – the connection string to Azure service bus instance
2. QueueName – service bus queue name
3. MetricName – the name of the application insights (configured for the function app) metric
4. outboundContainer – the name of the blob storage container in which the messages get put after pulling from the service bus queue
5. TargetStorageAccount – the connection string for the above storage account
6. WaitMs – how many mS to wait in each letter of string copy (to simulate busyness)
7. metricUpdatePattern – CRON pattern for the timed function that sets the metric value from the queue length (“*/15 * * * * *” is every 15 seconds)

It may also be useful (for test purposes) to limit the scale out of the function as service bus is used by the function runtime to scale out to multiple instances – thus getting more work done in parallel. This is what is needed for a real workload, but for this demonstration, limiting the function to a few instances (in the scale out section) is useful to be more representative of a background processing activity.

Summary

With the use of a novel form of JMeter JMX file, combined with Azure Load Testing and Application Insights custom metrics allows the load testing and progress monitoring of background processes in an efficient manner. The reports then generated in Azure Load Testing give a view of the progress of the background process.

Learn more

• View the AsyncLoadTest repository on GitHub
• What is Azure Load Testing?
• How Azure Backup Center deals with constant change
• How to create an effective test plan

The post How you should be load testing your background services appeared first on Microsoft Industry Blogs - United Kingdom.

In this article we will make a static web app and deploy to Azure using GitHub actions.

What is a static web app?

In modern web development, the front end application that the user accesses in their browser is often purely HTML, CSS and JavaScript, meaning the application can be used entirely with the user’s browser. This is a static web application and uses principals often referred to as JAM Stack (JavaScript, APIs, Markup). 

Any dynamic interactions are achieved by APIs hosted within separate applications, such as Azure Functions. This allows the applications to be maintained and hosted separately with their own deployment pipelines.

Separating the frontend to a static web app allows the hosting to be more lightweight than a full application, including server-side technologies, and supports a microservice architecture. 

In Azure, we can host our static application on Azure Static Web Apps.

Creating our Static Web App

Let’s start by creating our repository in GitHub:

I am going to use GitHub Codespaces to build my application, but you can build on your own machine and commit to your repository using your preferred development tools. If using GitHub, you can click on the “Code” button and select “Codespaces” to set up a new space for this repo. Codespaces sets up a development environment in the cloud – if you have used Visual Studio Code, this will look very familiar!

I am most experienced with .NET technologies so I am going to use a Blazor Web Assembly as my static web app here, but you can use your preferred framework such as React or Vue.

In the Codespaces “terminal” tab, run dotnet new blazorwasm to create a templated Blazor application with some sample pages.

Now, if we look at the files in the file directory, we can see the folders and files for the template application. Let’s see what it looks like in browser – run dotnet run and it will build and run on a localhost port. 

Of course, in a real application we would make a lot of changes before being ready for deployment, but for now we can commit and push our changes to our GitHub repo.

Creating your Static Web App

Now that we have our application running locally and pushed to our repo, let’s get our Azure Static Web App ready to deploy to. Within Azure create a resource of type “Static Web App”, selecting the relevant details for your subscription, resource group, plan type and region.

You will have an option to choose where to deploy from. In this example I am choosing my GitHub repo but you can also link to Azure DevOps or another source control. You can also deploy to your application using the Azure SWA CLI but in this example I want to show the integration with GitHub.

When selecting GitHub, I am asked to authenticate to my GitHub account and select the repo and branch. As previously mentioned, you can choose your relevant framework, Blazor in my example. You can tell it which folder within your repo to use in your deployment, as well as any API links such as Azure Functions (but we have static client side assets only in our example). We can then select “review + create” and let Azure takeover.

Initially, your application will look like this holding page:

While Azure creates the SWA resource, you will see a new commit with a .yml file in your GitHub repo. This represents a GitHub Action, a workflow that can automatically run on push or PR for example. If you haven’t worked with .yml or Actions before, this is a great way to understand how they work. The auto-generated one has configuration for deploying to Azure on push to your repo. Let’s check the “Actions” tab and we’ll see it working on our deployment:

You can take a look at the .yml file in this example over on GitHub.

Now that we have run this Action successfully, lets refresh our Azure Static Web App and (*drumroll*)… it’s now showing our Blazor application! Our GitHub pipeline was successful and will auto deploy on push to main.

Reviewing your PRs on preview environments

One feature I find really powerful on Azure SWA is the ease of preview environment creation. First, if we look at our .yml file, we can see there is a workflow for pull request creation. To test this out, I am back to my codebase and make a change to the menu colour and commit the changes to a branch. We can then create a Pull Request from this branch.

If we have a look on the Actions tab again, we’ll see it’s running on my “example-branch”.

Once this completes, we can see a URL in the detail of the Action workflow. This is the deployment location of the preview environment for this PR on Azure, with the main branch still being on the original SWA URL. I love this feature as it means that as well as reviewing code in a PR, we can also view the changes on a live web app as part of our review. We could also share the link with project stakeholders to get immediate feedback before merge and deployment to main.

Here we can see both of the deployed web apps from the main branch and PR branch side by side:

From within the Azure portal, you can see all your active environments in the “environments” tab. Here we can see the production URL (based on main branch) and any preview environments (my “example- branch” in this example):

Once the reviewer is happy with the changes, they can approve and merge. Once merged, the GitHub action will automatically close the PR preview environment and deploy the changes to the main static web app.

Summary

And just like that, we have created a new application and deployed it to Azure Static Web Apps! As shown, with GitHub actions we can create reliable and repeatable deployment and review workflows using .yml configuration.

Hopefully this has given you an overview of the benefits of these tools and will let you integrate to your own processes. Have fun!

Learn more

• You can find more from Carole on her blog
• Getting started with GitHub
• A look at the announcements from GitHub Universe

The post Using GitHub Actions to deploy an Azure Static Web App appeared first on Microsoft Industry Blogs - United Kingdom.

GitHub is a development platform that enables you to host and review code, manage projects, and build software alongside 50 million developers.

Why is everyone building on GitHub? Because it provides the important DevOps features companies and organisations of all sizes need for their public and private projects. Whether it’s planning features, fixing bugs, or collaborating on changes, GitHub is the place where the world’s software developers gather to make things – then make them better.

In addition to providing a platform for collaborative software development, GitHub also offers a workflow designed to optimise use of its various features. While this unit offers a cursory overview of important platform components, it’s recommended that you first review Understanding the GitHub flow.

Resources

• Microsoft Learn for GitHub

Get started with GitHub

With Microsoft Learn, you can kick off your journey into GitHub with easy to understand training – and best of all, it’s free! This is the perfect way to work through new tools and processes.

• Introduction to GitHub
• Work with Azure Repos and GitHub
• Manage repository changes by using pull requests on GitHub

Learn more about GitHub

Already using GitHub and want to push your skills further? There’s plenty more to explore and discover.

• Introduction to GitHub Actions
• Plan Agile with GitHub Projects and Azure Boards
• Build and deploy applications to Azure by using GitHub Actions
• Automate GitHub by using GitHub Script

Further resources

• New Azure features and functionality for December 2022
• A look at the announcements from GitHub Universe
• Why GitHub Actions is invaluable for devs
• Sign up for the Monthly TechNet UK IT Pro Newsletter for more!

The post Getting started with GitHub appeared first on Microsoft Industry Blogs - United Kingdom.

Day 1 of GitHub Universe is complete! Here’s a quick recap of what was announced during the keynote. If you missed the keynote, or want to catch up on any of the on-demand sessions, you can watch them on the GitHub Universe website.

GitHub Copilot

GitHub Copilot is an AI pair programmer that uses OpenAI Codex to suggest code and entire functions in real time, right from your editor. AI will soon be integrated into every aspect of the developer experience, so GitHub Copilot is becoming even more accessible.

One such area is the addition of voice commands. “Hey, GitHub!” enables voice-based interaction with GitHub Copilot, enabling the benefits of an AI pair programmer while reducing the need for a keyboard.

Soon, businesses will be able to purchase and manage seat licenses for GitHub Copilot for their employees.

GitHub Codespaces

Getting stuck into a new codebase or a new tool can be daunting, from downloading the correct dependencies to setting up your environment. GitHub Codespaces makes this easier with its new search and navigation functionality, which lets you easily find what you need for your projects.

Individual developers will get up to 60 hours of GitHub Codespaces for free every month, and you can get building in a matter of seconds. The powerful code search and code view features enable you to rapidly search, navigate, and understand code, right from GitHub.com.

GitHub Projects

With GitHub Projects being developer-first and truly flexible, it not only adapts to your current planning processes, but it encourages you and empowers you to evolve and iterate as you go.

There have been over 100 new features and updates since the launch of the new GitHub Projects last year. There are many more to come, including the following:

The Roadmap feature provides you with next level visualisation of your projects. Alongside tables and boards, you can create a roadmap view to visualise your work items across a timespan, plan and track a body of work over time, or watch the progress towards a deadline.

Tasklists can turn issues into tasks, converts tasks to issues, visualises your relationships in GitHub Projects, and more. This is all presented in a polished, new UI.

Projects on GitHub Mobile bring the power of GitHub to the palm of your hand, enabling you to contribute and collaborate from anywhere.

More from GitHub Universe

That’s not all! There were also important updates to GitHub Enterprise Cloud, new security features, and how GitHub remains focussed on open source software. You can find all of these updates, as well as more information on the new features covered above, on the GitHub Universe announcement article.

Useful Links

• Check out Microsoft Learn TV!
• Check out on-demand sessions you might have missed
• Follow the conversation on the #GitHubUniverse hashtag!
• Why GitHub Actions is invaluable for devs

The post A look at the announcements from GitHub Universe appeared first on Microsoft Industry Blogs - United Kingdom.

Learn GitHub Actions. If you already are familiar with it, deepen your knowledge.

As programmers, we tend to focus on computing languages and perhaps the integrated development environment (IDE) we use. That makes sense, and there’s plenty in computing culture to push us in the direction of study of the latest syntax, or the best libraries and frameworks that apply to our work. Yes, dive into Selectors Level 4 and Jupyter and RxJava and Big Data Clusters. Those will always be fundamental.

You also need to experience for yourself the workflow automation that Actions offers. Think of it as programming, but on a higher level. You absolutely need the basics of your chosen technologies; at the same time, workflow automation helps you leverage that knowledge in a way that’s hard to understand until you try it for yourself.

Force multipliers

We’ll look at Actions in several different aspects, because it’s so easy to underestimate otherwise.

GitHub started as a rather passive repository: developers put source code there, and developers retrieved source code from it. GitHub offered new services through the years, including Pages to host websites based on stored source.

Actions activates all the previous capabilities, because Actions executes source. Most introductions to Actions present its CI/CD capabilities, and those indeed are important to the point of being indispensable for many development projects. CI/CD is almost a side effect, though, of Actions’ more general collaborative and computational capabilities.

Think for a moment about applications out in the real world. Amazing results are now feasible because what used to be top-level research projects in motion detection or natural-language processing or geographic information systems have been reduced to open-source libraries that anyone can incorporate. Actions helps focus some of that same power on our domain: source code. Source repositories no longer are passive dumps where we pour our source in, but increasingly active team members that automate more and more of the tedious work of programming.

And that is true because Actions isn’t just a tool, but a workplace for sharing best practices. Consider, say, security vulnerabilities. You probably recognise the benefits of automatic scanning of your source code to identify potential vulnerabilities. You might even recognise that Actions, like other CI/CD tools, is a great way to automate those scans to find problems long before they can affect your users. But there’s more! Actions also supports an entire marketplace of shareable executable pieces that embody best practices in this and related areas. You don’t have to reinvent common wheels for issuing notifications and tracking progress and reporting results. Others have already done this, and many of those achievements are available for your use.

Review stale issues that deserve closure? There’s an Action for that. Help newcomers set up an effective Go development environment? That’s in there. Customise localisation processes so your application speaks like a native? Actions can help.

You owe it to yourself to learn enough of Actions to handle as many of the administrative processes around development as possible. That will free you to turn your attention back to the programming you like, with the security that Actions is taking care of the other parts.

Look to the future

Learn the latest Actions news, because, along with all the benefits and features mentioned above, Actions is more and more a platform for collaboration by the distributed teams of the post-pandemic future.

Learn more

• .NET Loves GitHub Actions: Intro to GitHub Actions for .NET
• GitHub Actions documentation
• Code-scanning with GitHub Actions

The post Why GitHub Actions is invaluable for devs appeared first on Microsoft Industry Blogs - United Kingdom.