Category: .Net

Categories
.Net Azure SDK

Integrating Azure Services to your own project

In this post, I want to share what options do we have as software developers to integrate Azure services to our own projects.

Go to https://azure.microsoft.com/en-us/downloads/
and see that we have couple of options or tools to integrate Azure services. First, we have the Unified SDKs. The Unified SDK is the new and improved SDK from the original Azure SDK. It is available in Java, Python, .NET, JavaScript / TypeScript. 

Next, we have the original SDKs. It is available for Go, Java, PHP, Python, .NET, and JavaScript / TypeScript. 

If you enjoy working on a terminal / command window, Azure also has command line tools. Currently there 4 tools in this space:  Azure command-line interface, PowerShell, AzCopy Command-Line Tool for Azure Storage, and Azure Storage Emulator.

In addition to SDK and command line tools, Azure has standalone tools. Currently, there are 3 standalone tools: Azure Storage Explorer, Azure Data Studio, and Azure CloudShell.

If you don’t see your programming language listed here, let me know how you have integrated Azure services into your project. 

 

Categories
.Net AWS CodeDeploy General

Creating AWS CodeDeploy Deployments Using .NET SDK

This is part 3 in a series dedicated to AWS CodeDeploy API using .NET SDK. In part 1, I created the CodeDeploy application using ASP.NET Core MVC, C#, and DynamoDB. In part 2, I created the deployment group which has settings for alarms, load balance, auto scaling groups, deployment styles, and other settings.

In this post, I want to concentrate on creating the deployment. In the deployment request, you can specify revision information (Github or S3 settings), deployment group, auto rollback configuration, and other settings.

Talk is cheap. Show me the code!

If you want to follow along, you can visit my github repo at https://github.com/agileraymond/DotNetDeployments. Now that you have a reference to the repo, let’s modify our controller so we can display our view.

This controller action displays our AddDeployment view.

There is a limitation with this view since it only displays S3 settings. In a future post, I will revisit this view and add the Github repo as well. I wanted to get something working in a short amount of time. When the user clicks on Add Deployment button, it will call a Post controller action to trigger a new deployment.

If the user entered all required information, a new deployment will be created in the AWS CodeDeploy console.

If you want to read more about the AWS .NET SDK, follow this link https://docs.aws.amazon.com/sdkfornet/v3/apidocs/Index.html.

If you have any questions or issues with this code, contact me via twitter @agileraymond.

Have a nice day!

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
.Net Agile General

Last Deployment of 2017


Yesterday we completed our last deployment of 2017. Web sites, WCF services, Web Api, Windows Services, and a PowerBuilder app were deployed without major issues. Our sprints run for 2 weeks and we tried to deploy at least once a month.

In this post, I want to share some of the tools we use at MDBuyline to ship high quality software.

Atlassian Jira
Our business analysts meet with our internal users on a regular basis. Sometimes these conversations take place informally during lunch or when they meet at the hall. The conversation goes something like this: “hey Bob, how are you? By the way, I wanted to show you an issue that I’m having with our website.” During these conversations, our analysts will gather enough information to create a user story. Bob will login to Jira and provide a brief description of the issue or feature request. The more information they provide the better. Adding visual aids also helps developers understand these stories better.

These stories will go to a backlog. Every other week we (developers and BA) will meet to go over these stories and also to set priorities for our next sprint. Currently we are in Sprint 47 and it will end next Thursday. Our sprints are 2 weeks long. We also have a scrum master that helps the team manage stories, priorities and deadlines.

Continuous Integration

We currently use subversion for our source control but will be migrating to git soon. Before we start working on a new story, we create a new branch based on the latest change of trunk (master in git). To continuous build our projects, we use Jenkins to handle our .NET builds and also our deployments. All of our projects have a Jenkins job that is set to build against the trunk version. The hassle with working with branches is that we have to ask our team lead to add a new Jenkins job and point it to our new branch. Hopefully with out Git migration, these setup will be handle automatically.

Continuous Deployment

After Jenkins completes building our projects, we use different PowerShell scripts to deploy web sites and web services to the right environment. We have 3 environments: dev, test, and prod. Let me give you an example so this becomes clear. Let’s say that we have a .NET website and it needs to be setup with Jenkins. Our team lead will add a new Jenkins job and set it up with subversion authentication, msbuild arguments, and PowerShell scripts. This job is build against the trunk version. Since we have to create a branch, our team lead will create a new Jenkins job based on the job that points to trunk. After creating the new job, the team lead will modify the url to point to the branch instead of the trunk url. At this point, we should be able to trigger a build and create artifacts. To move these artifacts from our Jenkins server to the correct environment, we use PowerShell scripts to copy files from Jenkins to server dev-win for example.

Summary

This year is coming to an end. For me personally, it has been a great year adding new features to our software products. Our production environment is in great shape since we ship high quality code. Jira helps us create sprints with the right items to work on. Jenkins helps us with our continuous integration. PowerShell scripts deploy our software efficiently and in a timely manner.

 

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

 

 

Categories
.Net ASP.NET ASP.NET MVC AWS CI Cloud

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

Categories
.Net Agile code review

Benefits of Performing Code Reviews

The only constant is change. In 2015, we did not have a formal code review process. However in 2016, we decided to change how we build software. Reliable software. Now we have introduced a formal code review process. In a nutshell, we have to pull down the subversion branch or branches and review each revision. The review process also involves compiling code, running unit tests, and trying to break the code. With this in mind, I wanted to share the benefits of performing code reviews.

Reduce Bugs

While performing code reviews for a year, we have concluded that bugs have been reduced significantly. The developer looking at the code changes is wearing a quality analyst hat during this time. If the code review is done correctly, he or she should find bugs. Sometimes it is a simple misspelled word, other times code won’t compile, or a unit tests fails. Many studies have found that finding bugs during development is less expensive than finding the same bug in production. If we encounter a bug six months from now, the developer will have to spend more time understanding the bug and trying to come up with a feasible solution.

Get Familiar with Code

Many times we have to review code that we have never seen. This is a great opportunity to learn about it. Sit down with the developer and ask questions. In our team, we have a developer who is in charge of applications written with PowerBuilder. He asked me to review his code and we sat down together to complete this important step in our development process. Most of our applications are written with .Net but having the knowledge of the PowerBuilder applications allow us to get familiar with all of our applications. Don’t be afraid to learn something new.

Learn New Tips and Tricks

Recently we had the opportunity to use PostgreSQL within a .Net application. Our team spent a lot time looking at syntax because it was our first time using PostgreSQL. One of the things we had to figure out was how to set the primary key. At the beginning we created sequences and it was a 2 step process. However when I had to do a peer review, I did not see a sequence created but a serial. Using serial was much simpler and the team liked the simplicity of using serial vs sequence. We also learn new tips when reviewing code together. Developer and reviewer sitting next to each other discussing code changes. Many times we picked keyboard shortcuts and tricks that improved how we built software.

Keep Code Consistent

If you look at our code base, it looks like the same developer wrote it. It contains the same architecture. It uses the same naming convention. Having a formal peer review process has allowed our team to keep the code consistent. This also helps new developers jump right into our code and be productive. The new developer does not have to learn 3 or 4 different architectures.

There are many benefits in doing code reviews. In our experience, we have seen the number of bugs reduced because bugs were found during development. Our developers were able to fix the bugs while we were in development. We have also be able to keep a consistent code base with the same architecture.

 

Categories
.Net ASP.NET ASP.NET MVC AWS CI

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

winsrv2016

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

Categories
.Net C# Visual Studio

Read error messages

My friend, Bruce, was having issues building a software project. He tried different things to solve it but did not succeed. He spent hours with this problem. Since I was watching a soccer match, I didn’t take time to help him.

After the game was over, I took 5 minutes out of my busy schedule to see what the issue was.

He had a .Net solution that contained 12 projects and 1 of those projects refused to build. This project was a base project where other projects depended on to build the entire solution.

First, we tried to clean the solution but still refused to cooperate. Next, I asked Bruce to show me the subversion pending changes. He had a lot of pending changes but they were simple classes.

After that, we tried to build individual projects until we narrowed it down to 1 project. We knew that it failed to build but we did not see the actual error message.

I asked Bruce to display the output window and read the error message. The error message said, “unable to build project since it references another project with a higher .Net framework version.” Most of the projects in the solution were using version 4.0. Finally, we knew what the problem was. He updated all projects to use .Net framework version 4.5.2 to match the version of the library.

Build succedded.

After spending time with this issue, I came to the conclusion that reading the actual error message will eventually help you solve it.