\ud83d\ude80 As developers, we’ve all experienced the frustration of manual deployments. You finish a feature, run tests locally, create a build, copy files to a server, and hope everything works in production. The process is time-consuming, repetitive, and prone to mistakes.<\/p>\n
\ud83d\udd04 This is where CI\/CD comes in.<\/strong><\/p>\n CI\/CD (Continuous Integration and Continuous Deployment)<\/strong> helps automate the software delivery process, allowing teams to build, test, and deploy applications with confidence.<\/p>\n In this blog, I’ll walk through how to set up a simple CI\/CD pipeline for an ASP.NET Core application using GitHub Actions.<\/p>\n Before jumping into the implementation, let’s briefly understand the concepts.<\/p>\n Continuous Integration (CI)<\/strong> is the practice of automatically building and testing your application whenever code is pushed to the repository. This helps catch issues early and ensures that new changes don’t break existing functionality.<\/p>\n Continuous Deployment (CD)<\/strong> takes things a step further by automatically deploying validated code to an environment such as staging or production.<\/p>\n \ud83d\udccc The typical workflow looks like this:<\/p>\n With this approach, deployments become faster, safer, and more reliable.<\/p>\n GitHub Actions is integrated directly into GitHub and uses YAML files to define workflows.<\/p>\n Key benefits include:<\/p>\n For most .NET projects, GitHub Actions provides everything needed to automate the delivery pipeline.<\/p>\n GitHub Actions workflows are stored inside the repository under:<\/p>\n Let’s create a file called:<\/p>\n A typical ASP.NET Core solution may look something like this:<\/p>\n MyApplication\/ Using the solution file is usually better than relying on the current directory because the solution can contain multiple projects.<\/p>\n The following workflow runs whenever code is pushed to the main<\/strong> branch:<\/p>\n GitHub Actions runners start with a clean environment. This checkout<\/strong> action downloads your repository code so the workflow can work with it.<\/p>\n This installs the required .NET SDK on the GitHub Actions runner.<\/p>\n Make sure this version matches the framework your application uses.<\/strong><\/em><\/p>\n For example:<\/p>\n .NET 8 \u2192 8.0.x<\/strong> This restores all NuGet packages required by the projects in the solution.<\/p>\n Here we explicitly provide the solution path.<\/p>\n The –-configuration Release<\/strong> option creates a Release build, while –no-restore prevents NuGet packages from being restored again because we already restored them in the previous step.<\/p>\n This executes the automated tests in the solution.<\/p>\n The ‘–no-build’<\/strong> option avoids building the solution again because it was already built successfully in the previous step.<\/p>\n This keeps the pipeline more efficient.<\/p>\n One of the biggest benefits of CI is preventing broken code from reaching production.<\/p>\n Imagine a developer accidentally introduces a bug into a critical service. Without automated testing, the issue might only be discovered after deployment.<\/p>\n By including the following step:<\/p>\n every commit is validated automatically.<\/p>\n This gives the team immediate feedback whenever a change introduces a failure.<\/p>\n After a successful build and test execution, the next step is creating a deployable package.<\/p>\n We can publish the ASP.NET Core application using:<\/p>\n The generated files are placed inside the publish<\/strong> folder and can be deployed to a server, Docker container, or cloud platform.<\/p>\n Instead of deploying the published files directly, we can first store them as a GitHub Actions artifact.<\/p>\n Now the published application is available as a workflow artifact.<\/p>\n Artifacts are especially useful when CI and CD are separated into different jobs or workflows.<\/p>\n A common delivery flow is:<\/p>\n For teams hosting applications in Azure App Service, deployment can be fully automated.<\/p>\n First, store the Azure publish profile in GitHub Secrets.<\/p>\n Then add a deployment step:<\/p>\n Now the published application can be deployed automatically after the CI process succeeds.<\/p>\n For production workloads, teams should also consider stronger authentication approaches such as federated credentials\/OIDC rather than relying on long-lived deployment credentials.<\/p>\n A common mistake is hardcoding credentials directly in workflow files.<\/p>\n For example:<\/p>\n This should never be done.<\/p>\n Instead, store sensitive values inside GitHub Secrets and reference them securely:<\/p>\n You can create secrets from:<\/p>\n GitHub \u2192 Repository \u2192 Settings \u2192 Secrets and variables \u2192 Actions<\/strong><\/p>\n Examples of values that should generally be stored as secrets include:<\/p>\n This keeps sensitive information out of your source code.<\/p>\n For a production application, deploying every commit directly to production may not be the best approach.<\/p>\n A more controlled setup could look like:<\/p>\n You can maintain separate environments such as:<\/p>\n GitHub environments can also be used to control secrets and require approval before production deployment.<\/p>\n Once the basic pipeline is working, there are several ways to improve it.<\/p>\n Installing dependencies on every workflow run can take time.<\/p>\n actions\/setup-dotnet<\/strong> can be configured with NuGet caching:<\/p>\n This can reduce workflow execution time when dependencies haven’t changed.<\/p>\n Configure branch protection rules so that pull requests must pass CI checks before they can be merged.<\/p>\n This prevents code that fails the pipeline from being merged into main<\/strong>.<\/p>\n For production deployments, consider requiring manual approval.<\/p>\n This gives the team one final checkpoint before changes reach production.<\/p>\n Treat pipeline failures as high-priority issues.<\/p>\n A failing pipeline can indicate:<\/p>\n A healthy pipeline should provide fast and reliable feedback to developers.<\/p>\n Putting everything together, our CI workflow now looks like this:<\/p>\n This gives us a simple but practical CI pipeline:<\/strong><\/p>\n From here, the artifact can be consumed by a separate deployment job or workflow.<\/p>\n CI\/CD<\/strong> is no longer a luxury for modern software teams\u2014it\u2019s a necessity.<\/p>\n By automating builds, tests, and deployments with GitHub Actions, .NET developers can spend less time on repetitive tasks and more time building valuable features.<\/p>\n The initial setup may take an hour or two, but the long-term benefits are substantial. Faster releases, fewer deployment mistakes, and greater confidence in production changes make CI\/CD one of the highest-value improvements a team can implement.<\/p>\n Build it once. Automate it. Deploy with confidence.<\/strong> \ud83d\ude80<\/p>\n","protected":false},"excerpt":{"rendered":" \ud83d\ude80 As developers, we’ve all experienced the frustration of manual deployments. You finish a feature, run tests locally, create a build, copy files to a server, and hope everything works in production. The process is time-consuming, repetitive, and prone to mistakes. \ud83d\udd04 This is where CI\/CD comes in. CI\/CD (Continuous Integration and Continuous Deployment) helps […]<\/p>\n","protected":false},"author":1266,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"iawp_total_views":14},"categories":[5867],"tags":[1853,4252,1892,5627],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/81612"}],"collection":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/users\/1266"}],"replies":[{"embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/comments?post=81612"}],"version-history":[{"count":18,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/81612\/revisions"}],"predecessor-version":[{"id":82004,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/posts\/81612\/revisions\/82004"}],"wp:attachment":[{"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/media?parent=81612"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/categories?post=81612"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.tothenew.com\/blog\/wp-json\/wp\/v2\/tags?post=81612"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}\ud83d\udd04 What is CI\/CD?<\/h2>\n
\ud83d\udc68\u200d\ud83d\udcbb Developer\r\n \u2193\r\n\ud83d\udcc2 GitHub Repository\r\n \u2193\r\n\u26a1 GitHub Actions\r\n \u2193\r\n\ud83d\udd28 Build\r\n \u2193 \r\n\ud83e\uddea Test\r\n \u2193\r\n\ud83d\udce6 Publish\r\n \u2193\r\n\u2601\ufe0f Deploy to Staging\r\n \u2193\r\n\u2705 Approval\r\n \u2193\r\n\ud83d\ude80 Production<\/pre>\n
\u2699\ufe0f Why GitHub Actions?<\/h2>\n
\n
\ud83d\udee0\ufe0f Creating the Workflow<\/h2>\n
.github\/workflows<\/pre>\n
dotnet-ci.yml<\/pre>\n
\n\u2502
\n\u251c\u2500\u2500 src\/
\n\u2502 \u251c\u2500\u2500 MyApplication.Web\/
\n\u2502 \u2502 \u2514\u2500\u2500 MyApplication.Web.csproj
\n\u2502 \u2502
\n\u2502 \u251c\u2500\u2500 MyApplication.Core\/
\n\u2502 \u2502 \u2514\u2500\u2500 MyApplication.Core.csproj
\n\u2502 \u2502
\n\u2502 \u2514\u2500\u2500 MyApplication.Infrastructure\/
\n\u2502 \u2514\u2500\u2500 MyApplication.Infrastructure.csproj
\n\u2502
\n\u251c\u2500\u2500 tests\/
\n\u2502 \u2514\u2500\u2500 MyApplication.Tests\/
\n\u2502 \u2514\u2500\u2500 MyApplication.Tests.csproj
\n\u2502
\n\u251c\u2500\u2500 MyApplication.sln
\n\u2514\u2500\u2500 .github\/
\n\u2514\u2500\u2500 workflows\/
\n\u2514\u2500\u2500 dotnet-ci.yml<\/p>\n\ud83d\udd28 Basic CI Workflow<\/h2>\n
name: ASP.NET Core CI\r\n\r\non:\r\n push:\r\n branches:\r\n - main\r\n\r\njobs:\r\n build:\r\n runs-on: ubuntu-latest\r\n\r\n steps:\r\n - name: Checkout Source\r\n uses: actions\/checkout@v4\r\n\r\n - name: Setup .NET\r\n uses: actions\/setup-dotnet@v4\r\n with:\r\n dotnet-version: '9.0.x'\r\n\r\n - name: Restore Dependencies\r\n run: dotnet restore MyApplication.sln\r\n\r\n - name: Build Application\r\n run: dotnet build MyApplication.sln --configuration Release --no-restore\r\n\r\n - name: Run Tests\r\n run: dotnet test MyApplication.sln --configuration Release --no-build<\/pre>\n
\ud83d\udd0d What is happening here?<\/h2>\n
Let’s break the workflow down.<\/h3>\n
1. Checkout Source<\/h3>\n
- name: Checkout Source\r\n uses: actions\/checkout@v4<\/pre>\n
2. Set up .NET<\/h3>\n
- name: Setup .NET\r\n uses: actions\/setup-dotnet@v4\r\n with:\r\n dotnet-version: '9.0.x'<\/pre>\n
\n.NET 9 \u2192 9.0.x<\/strong><\/p>\n3. Restore Dependencies<\/h3>\n
- name: Restore Dependencies\r\n run: dotnet restore MyApplication.sln<\/pre>\n
4. Build Application<\/h3>\n
- name: Build Application\r\n run: dotnet build MyApplication.sln --configuration Release --no-restore<\/pre>\n
5. Run Tests<\/h3>\n
- name: Run Tests\r\n run: dotnet test MyApplication.sln --configuration Release --no-build<\/pre>\n
\ud83e\uddea Adding Automated Testing<\/h2>\n
- name: Run Tests\r\n run: dotnet test MyApplication.sln --configuration Release --no-build\r\n\r\n<\/pre>\n
\ud83d\udce6 Publishing the Application<\/h2>\n
- name: Publish Application\r\n run: dotnet publish src\/MyApplication.Web\/MyApplication.Web.csproj --configuration Release --output .\/publish<\/pre>\n
\ud83d\udce6 Uploading the Build Artifact<\/h2>\n
- name: Upload Artifact\r\n uses: actions\/upload-artifact@v4\r\n with:\r\n name: myapplication\r\n path: .\/publish<\/pre>\n
Build\r\n \u2193 \r\nTest\r\n \u2193\r\nPublish\r\n \u2193 \r\nArtifact\r\n \u2193\r\nStaging\r\n \u2193\r\nProduction<\/pre>\n
\u2601\ufe0f Deploying to Azure<\/h2>\n
- name: Deploy to Azure\r\n uses: azure\/webapps-deploy@v3\r\n with:\r\n app-name: ${{ secrets.AZURE_WEBAPP_NAME }}\r\n publish-profile: ${{ secrets.AZURE_PUBLISH_PROFILE }}\r\n package: publish<\/pre>\n\ud83d\udd10 Protecting Sensitive Information<\/h2>\n
password: MyPassword123<\/pre>\n
${{ secrets.DB_PASSWORD }}<\/pre>\nAZURE_WEBAPP_NAME\r\nAZURE_PUBLISH_PROFILE\r\nDB_PASSWORD\r\nAPI_KEY\r\nCONNECTION_STRING<\/pre>\n
\ud83c\udf0d Using Multiple Environments<\/h2>\n
Developer\r\n \u2193\r\nGitHub\r\n \u2193\r\nBuild\r\n \u2193\r\nTests\r\n \u2193\r\nStaging\r\n \u2193\r\nManual Approval\r\n \u2193\r\nProduction<\/pre>\n
\n
\u26a1 Improving the Pipeline<\/h2>\n
\u26a1 Cache NuGet Packages<\/h2>\n
- name: Setup .NET\r\n uses: actions\/setup-dotnet@v4\r\n with:\r\n dotnet-version: '9.0.x'\r\n cache: true\r\n cache-dependency-path: '**\/packages.lock.json'<\/pre>\n
\ud83d\udd12 Protect the Main Branch<\/h2>\n
\ud83d\udc40 Require Production Approval<\/h2>\n
\ud83d\udcca Monitor Pipeline Health<\/h2>\n
\n
\ud83e\udde9 Complete CI Workflow<\/h2>\n
name: ASP.NET Core CI\r\n\r\non:\r\n push:\r\n branches:\r\n - main\r\n\r\njobs:\r\n build:\r\n runs-on: ubuntu-latest\r\n\r\n steps:\r\n\r\n - name: Checkout Source\r\n uses: actions\/checkout@v4\r\n\r\n - name: Setup .NET\r\n uses: actions\/setup-dotnet@v4\r\n with:\r\n dotnet-version: '9.0.x'\r\n\r\n - name: Restore Dependencies\r\n run: dotnet restore MyApplication.sln\r\n\r\n - name: Build Application\r\n run: dotnet build MyApplication.sln --configuration Release --no-restore\r\n\r\n - name: Run Tests\r\n run: dotnet test MyApplication.sln --configuration Release --no-build\r\n\r\n - name: Publish Application\r\n run: dotnet publish src\/MyApplication.Web\/MyApplication.Web.csproj \\\r\n --configuration Release \\\r\n --output .\/publish\r\n\r\n - name: Upload Artifact\r\n uses: actions\/upload-artifact@v4\r\n with:\r\n name: myapplication\r\n path: .\/publish\r\n<\/pre>\n
\ud83d\udce5 Checkout\r\n \u2193\r\n\u2699\ufe0f Setup .NET\r\n \u2193\r\n\ud83d\udce6 Restore\r\n \u2193\r\n\ud83d\udd28 Build\r\n \u2193\r\n\ud83e\uddea Test\r\n \u2193\r\n\ud83d\udce6 Publish\r\n \u2193\r\n\u2601\ufe0f Upload Artifact<\/pre>\n
\ud83d\ude80 Final Thoughts<\/h2>\n