.Net AWS CI Code Deployment CodeDeploy Continuous Delivery

Creating AWS CodeDeploy Deployment Groups Using .NET SDK

In a previous post, I shared how to create codedeploy applications using the AWS .NET SDK. Adding an application is the foundation to get codedeploy working correctly. In this post, I want to continue this series and show you how to add deployment groups.

To see what parameters we need to add deployment groups, I’m going to read the official documentation here. Find the Amazon.CodeDeploy documentation on the left of the page, and then click on AmazonCodeDeployClient. All codedeploy operations will be handled by the AmazonCodeDeployClient. The method we need is CreateDeploymentGroupAsync. Since we are using .NET Core 2, we need to use the Async methods. CreateDeploymentGroupAsync takes 2 parameters: CreateDeploymentGroupRequest and CancellationToken.

These are CreateDeploymentGroupRequest’s properties:

– AlarmConfiguration: Gets and sets the property AlarmConfiguration. Information to add about Amazon CloudWatch alarms when the deployment group is created.

– ApplicationName: Gets and sets the property ApplicationName. The name of an AWS CodeDeploy application associated with the applicable IAM user or AWS account.

– AutoRollbackConfiguration: Gets and sets the property AutoRollbackConfiguration. Configuration information for an automatic rollback that is added when a deployment group is created.

– AutoScalingGroups: Gets and sets the property AutoScalingGroups. A list of associated Auto Scaling groups.

– BlueGreenDeploymentConfiguration: Gets and sets the property BlueGreenDeploymentConfiguration. Information about blue/green deployment options for a deployment group.

– DeploymentConfigName: Gets and sets the property DeploymentConfigName. If specified, the deployment configuration name can be either one of the predefined configurations provided with AWS CodeDeploy or a custom deployment configuration that you create by calling the create deployment configuration operation. CodeDeployDefault.OneAtATime is the default deployment configuration. It is used if a configuration isn’t specified for the deployment or the deployment group. For more information about the predefined deployment configurations in AWS CodeDeploy, see Working with Deployment Groups in AWS CodeDeploy in the AWS CodeDeploy User Guide.

– DeploymentGroupName: Gets and sets the property DeploymentGroupName. The name of a new deployment group for the specified application.

– DeploymentStyle: Gets and sets the property DeploymentStyle. Information about the type of deployment, in-place or blue/green, that you want to run and whether to route deployment traffic behind a load balancer.

– Ec2TagFilters: Gets and sets the property Ec2TagFilters. The Amazon EC2 tags on which to filter. The deployment group will include EC2 instances with any of the specified tags. Cannot be used in the same call as ec2TagSet.

– Ec2TagSet: Gets and sets the property Ec2TagSet. Information about groups of tags applied to EC2 instances. The deployment group will include only EC2 instances identified by all the tag groups. Cannot be used in the same call as ec2TagFilters.

– LoadBalancerInfo: Gets and sets the property LoadBalancerInfo. Information about the load balancer used in a deployment.

– OnPremisesInstanceTagFilters: Gets and sets the property OnPremisesInstanceTagFilters. The on-premises instance tags on which to filter. The deployment group will include on-premises instances with any of the specified tags. Cannot be used in the same call as OnPremisesTagSet.

– OnPremisesTagSet: Gets and sets the property OnPremisesTagSet. Information about groups of tags applied to on-premises instances. The deployment group will include only on-premises instances identified by all the tag groups. Cannot be used in the same call as onPremisesInstanceTagFilters.

– ServiceRoleArn: Gets and sets the property ServiceRoleArn. A service role ARN that allows AWS CodeDeploy to act on the user’s behalf when interacting with AWS services.

– TriggerConfigurations: Gets and sets the property TriggerConfigurations. Information about triggers to create when the deployment group is created. For examples, see Create a Trigger for an AWS CodeDeploy Event in the AWS CodeDeploy User Guide.

To keep my code example concise, I’m going to only use required properties to add a deployment group. Let’s start by adding the controller actions. Take a look at the gist below:

The first action returns a view so we can fill out application name, deployment group name, and service role arn. Take a look at the view:

I’m only displaying the required fields to create a new deployment group. This is how I like to develop my applications: add small features that work and then add more features and keep improving those features. It is very difficult to add perfect code at first. It is constant improvements that will yield better applications.

When the user clicks on add button, the post action will take care of sending the request to the codedeploy client. If the call to CreateDeploymentGroupAsync is successful, we will see a new deployment group in the aws console. To be able to understand deployment groups, we have to understand development environments. We usually have dev, test, and production environments. These environments are usually separated from each other. Dev environment is usually open for all developers. Test might be use to test actual deployments. And production only a couple of engineers should have access to that environment. In CodeDeploy, deployment groups allow you to mirror your development environment when it comes to deployment. For 1 application, you can setup 3 deployment groups (dev, test, and production). Each group will be linked to an EC2 instance(s) or on-premises servers. In a future post, I will provide examples with all these properties. Stay tuned!

Next: Creating AWS CodeDeploy Deployments Using .NET SDK

.Net AWS C# CI Github

3 Things I learned During Hacktoberfest

Hacktoberfest is a month long initiative to promote collaboration using Github. DigitalOcean created this event a few years back. This year I decided to participate in this event. In this post I want to share the 3 things I learned during Hacktoberfest.

Learn something new

During our busy schedules at work, we’re focused on maintaining existing products. In many occasions, these products are using old technology. We have a very small web site running ASP.NET MVC 2. MVC 2 was released on March 2010 so this web site is using old technology that is 7 years old. We tried to upgrade this website to run a more recent version but we ran into migration issues and the effort was abandoned. Since this site is not a critical product in our company, we decided not to spent more time on it.

With the recent release of .NET Core 2, it’s very important that .NET developers stay on top of these changes. Last month I created a new project in github called  DotNetDeployments. This project was created to automate .NET deployments. No more copy and paste files between servers. In order for me to learn something new, I decided to base this project on .NET Core 2. Core 2 was released on August 2017 and there are major changes in relationship to previous versions. In addition to learning .NET Core 2, I also learned DynamoDB high level operations using the AWS SDK.

Solve your own problems

Before Hacktoberfest took place, I started brainstorming ideas for a new project. I wrote down some ideas but I was not happy with those projects. I wanted to solve bigger problems. I’ve worked in different industries and companies and there is always areas to improve. In my current position, we are using Jenkins for our continuous integration server and powershell scripts to deploy our applications. With this setup, we are able to deploy 95% of our projects. The other 5% are deployed by copy and paste. It is not fun. So I decided to create a new project to solve this problem. DotNetDeployments will handle our deployments using AWS CodeDeploy and powershell will be use to create IIS sites, and create Windows Services. The beauty of this project is that it can handle on-premises servers and also AWS EC2 instances. Since this is an open source project, I’m expecting the community to get involved and make this project even better.

People are willing to help

After creating DotNetDeployments, I created github issues to keep track of all things I wanted to accomplish. I added “hacktoberfest” and “help wanted” labels to my issues so I can communicate with the community that I needed help. It didn’t take long and I was receiving small pull requests. I was so excited that developers were willing to help a new project. I reviewed the code and was able to accept those pull requests. After the first pull requests, I decided to add AppVeyor to handle my automated builds. AppVeyor is really easy to use and their documentation is awesome. Now with CI in place, I created more issues to handle unit tests, and also to rearrange the folder structure. I received more pull requests and was happy to review and accept them. Some of these changes broke the build but I merged those changes since I had a different issue to update AppVeyor config file. These changes were necessary because our folder structure changed. I just want to thank all the contributors that are taking the time to make this project better. We’re not done yet but during Hacktoberfest we made a lot of progress.

In summary, Hacktoberfest was a very successful initiative by DigitalOcean and GitHub. During this month, I was able to learn new technologies and solve real problems that developers face every day. DotNetDeployments could not be possible without the help of the community. Thanks to all contributors.




.NET Build Server using Visual Studio Community 2017

In a previous post, I wrote about building a .NET continuous integration server using Windows Server 2016, Jenkins, and Build tools. For this setup, I avoided installing any Visual Studio software. In my opinion, it was a simple process to get everything installed and building correctly. Now that Visual Studio 2017 has been released, I want to setup a build server using the community edition. Here are the 7 steps I took to get a .NET build server using Visual Studio 2017 Community edition, Jenkins, Git, running on Windows Server 2016.

1. Launch a new Windows Server 2016 instance. I’m currently investing on learning AWS so I’ll use it as my cloud provider. Feel free to use Azure, Google Cloud or your own server.

2. Download and install Visual Studio 2017 Community edition. For this tutorial, I selected ASP.NET and web development option during the installation.

3. Download and install Jenkins. I selected version 2.46.1 for this tutorial. After installing Jenkins, you have the option to install recommended plugins or select them one by one. For this tutorial, I went with the option to installed recommended plugins.

4. Download and install Git. If you have a different source control tool, go ahead and install it. After installing Git, I went to the Global Tool Configuration section and updated the path to C:\Program Files\Git\bin\git.exe.

5. Install MSBuild plugin. Go to Manage Jenkins section and select plugins. From the available tab, find MSBuild and install it. I also updated the path in the Jenkins settings to C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin\msbuild.exe.

6. Create a new Jenkins job. I used the free style option. For the settings I use Git as my source control tool. Since I’m building a .NET solution, I selected the build action that uses MSBuild and give it the solution or project name.

7. Trigger a new build. If all of the steps above were done correctly, you should have a successful build.

Installing Visual Studio Community edition makes it easier to have a build server setup. After installing it, you get the .NET framework needed plus the MSBuild executable. In my previous setup, I had to install more software. Build Tools 2015, .NET framework 4.5.2, 4.6.2. Hopefully this post helps you setup a reliable build server for your .NET applications.


5 Easy Steps to Setup a .Net Build Server on Windows 2016


.NET developers have the luxury of using Visual Studio to write code. In my opinion, Visual Studio is one of best IDE in the market today. When you build your applications inside Visual Studio, you are using MsBuild to compile your code.

In the past, setting up a .NET build server without installing Visual Studio was challenging. Now that Microsoft is releasing more software as open source  software, setting up a .NET build server can be accomplish with no issues.

In this post, I want to share the steps I took to setup a .Net continuous integration server running on Windows 2016.

First, launch a new instance with Windows 2016. I’m using AWS but any cloud provider would work as well.

After launching the new Windows 2016 server, it is time to install the necessary software to create our build server.

  1. Install Microsoft .NET Framework 4.5.2 Developer Pack.
  2. Install Microsoft .NET Framework 4.6.2 Developer Pack.
  3. Install Microsoft Build Tools 2015.
  4. Install Jenkins 2.19.3.
  5. Copy files from developers’ machine located at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications to the same exact location on the new Windows 2016 server.

So far I have only tested this build server with a MVC website targeting .NET framework 4.5.2. Let me know if you run into any issues with this setup.

I hope to test different apps and also add support for .NET Core.

If you are using AWS, you can launch the same instance I have created by searching for “Jenkins Build Server 2.19.3”.

.Net CI

Available Options for Continuous Integration for .Net Applications

Continuous Integration

Continuous integration is a must practice in any software development team. It allows you to receive feedback instantly about the state of your project. In this post I’m going to share the available options to implement continuous integration for your .Net projects.


Jenkins is an open source tool written in Java. It has a nice UI to help you setup your project. The Jenkins community has also created many plugins to integrate with your favorite tools. It is easy to setup and configure. If you are not using a continuous integration server, I highly recommend Jenkins.


CruiseControl.NET is also an open source tool initially created by ThoughtWorks. Just like Jenkins, it has plugins available to integrate with bug management tools, source control, reporting, and others. The initial setup is easy but creating projects is more complicated since there is no UI available. You have to edit an XML configuration file.


AppVeyor is the new kid on the block. It’s a cloud based solution that relies on Azure for its infrastructure. In addition to continuous integration, it also offers continuous deployment. Scott Hanselman wrote a blog post about AppVeyor.

It is free for open source projects. For private projects, price start at $19 per month for 1 project and 1 concurrent job.


If you have used Jira, HipChat, Confluence before, you will feel at home with Bamboo. It is more that a continuous integration since it allows you to do continuous deployment. It also integrates with Jira, and Bitbucket for a smooth workflow.

Visual Studio Build

If you are invested in Team Foundation Server for your source code management, you can take advantage of the Build feature. The same Build feature is also available online with their cloud product called Visual Studio Online.

Team City

Team City is a very popular continuous integration for .net projects. You can find more about its features here. It is very pricey but well worth the price. TeamCity will not disappoint your team.


I have listed about these CI tools briefly but encourage you to play with them and see what works best for you. Let me know if you use a tool not listed here.