Category: Continuous Delivery

Categories
.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

Categories
.Net ASP.NET MVC AWS Code Deployment CodeDeploy Continuous Delivery

Creating AWS CodeDeploy Application Using .NET SDK

I’m a big fan of AWS and its cloud services. S3 has changed the way we store objects. EC2 has enabled us to spin up instances quickly and in a cost effective way. CodeDeploy helps developers deploy applications to EC2 instances and also on-premises servers. In this post, I want to share how to create a CodeDeploy application using the AWS .NET SDK.

First, create a new asp.net mvc project using Visual Studio or Visual Studio Code. Make sure to target .NET Core 2.0. Now that we have a new project, let’s add codedeploy nuget package. If you are using VS Code, use the built-in terminal and type “dotnet add package AWSSDK.CodeDeploy”. This will add the latest version of CodeDeploy. We also need to add an AWS nuget package to inject codedeploy service in our Startup.cs file. Run in the terminal “dotnet add package AWSSDK.Extensions.NETCore.Setup” to add this package.

Let’s modify our Startup.cs file to look like below:

In order to have access to AWS CodeDeploy api calls, we need to setup our credentials. For this example, I’m using a profile to store AWS access key id and secret access key. I’m storing the credentials outside my source code in a profile file so I can keep them secure. Also those credentials will be different between developers. To help you with this setup, follow this document to setup your AWS credentials and make sure to pay special attention to the profile section.

With the AWS profile in place, we need to add a reference to it. Take a look at my appsettings.json file. I named mine dotnetdeployments-profile since you can have multiple profiles.

We are ready to start looking that controller. Take a look at the controller below:

In connection with the controller, we also need to look at the view:

The add action in our controller displays the add view only. The view has a reference to a model called CreateApplicationRequest and this class has a property named ApplicationName. When the user clicks on the add button, a post will be triggered back to our controller. And finally, it will call the api method CreateApplicationAsync. If everything is setup correctly, we will receive a successful response and our application will be visible on the AWS console.

If you want to see a fully functional example, go to the github project dotnetdeployments and clone it locally to see a working example. Creating a CodeDeploy application is the first step in using this api. We also need to create deployment groups, deployment configs and other settings. Stay tuned for the next post in this series.

Next: Create deployment groups

Categories
AWS CodeDeploy Continuous Delivery Jenkins

Jenkins Plugin – AWS CodeDeploy

Our company uses Jenkins for our continuous integration. It is responsible for building .NET projects, and sometimes deploying our projects. One of the problems we are trying to solve is being able to deploy Windows services. Currently, we manually deploy these services. We copy and paste files to the right server and then run a batch file to install the service. This process is time consuming and error-prone. We decided to improve these manual deployments with a Jenkins plugin called AWS Codedeploy.

First thing that we need to do is install the Jenkins plugin. Go to your Jenkins site, and install CodeDeploy plugin and restart Jenkins.

Now that we have the plugin up and running, let’s update a job and add our code deploy settings. The plugin needs to know: application name, group name, region, revision info (s3 bucket and prefix), and other settings. Once we have our job setup with codedeploy settings, we can start modifying our applications to instruct aws codedeploy what to deploy and how to do deploy it. We need to add a yml file which contains what files need to be deploy. The file needs to be named appspec.yml and it needs to be in the root of project. Take a look at this page to see appspec examples.

In addition to the appspec file, we also need to install the aws codedeploy agent in our on-premise servers or aws instances. In our case, we will install the agent in our on-premise servers. After installing the agent, we need to register the servers with AWS CodeDeploy. In a nutshell, the agent is listening for request for applications to be deployed.

We now have our application and server ready and it is time to deploy our windows services. After Jenkins builds our .NET window service, the codedeploy plugin will register a new revision and start the deployment process. With the help of appspec hooks, we can use powershell to install and start the service. CodeDeploy provides hooks so that developers can integrate with the different events. We can use BeforeInstall, AfterInstall, ApplicationStart, and ValidateService hooks. For our example, we can use the AfterInstall hook to install the service and then start the service.

Now that we have fully automated our .NET deployments, our developers can spend more time adding new features.

Categories
ASP.NET Continuous Delivery General

Frustrated Driven Development

Frustrated Driven Development

I want to share a story about FDD or Frustrated Driven Development. A few years back, I worked in a very large asp.Net web site and the deployments were done manually. As you can imagine the chaos and errors caused by manual deployments. Sometimes we forgot to include all required steps to deploy the application. The instructions to our IT department will look like:

1. Create a back up copy of the entire site.
2. Delete all the files except the web.config file.
3. Copy the folder contents from this location d:\deployments\eStoreApp\05-20-2008\production into the production folder.
4. Open up the web.config file from production and update the following app settings:
a. Update emailAddress value from oldEmail@test.com to newEmail@test.com.

These instructions were very difficult to follow by our IT department and many times we encounter issues because one of the steps required to deploy the site was never performed. IT will blame engineers and engineers will blame IT. I guess both IT and engineers were used to this process and the frustration level was low. It was so painful that no one wanted to change or improve this process.

However, we got a new team member in our IT department. At the beginning, Bob followed the deployments instructions but he started questioning this process. Bob was frustrated and started talking with his manager. Bob said, “there must be a better way to deploy asp.net sites”. He gather data and found a product by red gate called deployment manager.

Bob approached me and said, “I don’t want to do manual deployments anymore. Can you help me test this new deployment tool from Red Gate?” I replied, “sure, what do you need from me?”. Bob said, “I just need a nuget package”.

Within a few weeks, we installed deployment manager in our different environments (QA, Staging, and Production) and both teams IT and engineers were happy and using this tool to automate our deployments.

Hopefully this story encourages other teams to use Frustrated Driven Development to identify what is causing pain and frustration in your team and using that energy to solve or improve those processes.