100 % Free Udemy Course: Unit Testing with xUnit.net from Beginner to Advanced!

Hey there!

I have a best seller course on Udemy which is about unit testing .NET Core 2 applications with XUnit.net.  It is called “Unit Testing .Net Core Applications with xUnit.net From Beginner To Advanced“, also demonstrate how you can use the mocking frameworks along with xUnit.Net and then run your tests in Visual Studio (both in Windows and on Mac), ReSharper, TeamCity or Bamboo!

Unit testing .NET Core applications with xUnit.net

The course is $99.99, however, I would like to offer it 100% Free to my blog readers and subscribers!

Simply enter your email address below, and I will email you back the coupon code of the Unit Testing .NET Core Applications with xUnit.net.



Online Course Bundles for Developers and DevOps! Buy five courses, pay for one!


So as you may already know I do teach on LinkedIn, Lynda, Udemy and Skill Share! My courses, which some of them are best sellers, are generally around two career paths:

  1. Become an awesome .NET engineer
  2. Become an awesome DevOps Engineer

I would like to reach out o as many as developers and DevOps engineers as possible so that more and more people learn the skills and knowledge they need to go to the next lever in their software engineering career.

In order to help you be able to enrol to the relevant courses with a lower cost, I have decided to create two bundles of courses and offer them with a huge discount. These two bundles are:

.NET Developer/Engineer Bundle

  1. Dependency Injection with .NET Core
  2. ASP.NET Core Identity (Authentication and Authorization)
  3. Unit testing .NET Core applications with xUnit.net
  4. Atlasssian Bamboo
  5. JetBrain TeamCity

DevOps Engineer Bundle

  1. Grafana, Graphite and StatsD monitoring framework
  2. New Relic application performance monitoring
  3. Jet Brain TeamCity
  4. Atlasssian Bamboo

When you buy either of these bundles you will get a free copy of my “Management and Leadership for Beginners” course too!

Each Bundle is only $29.99! Each of my courses are $99.99 so that is a whopping 95% discount!

Please choose the bundle that you want, and then pay via PayPal. I will send the course links to the email address that you use in your PayPal account to pay for the courses. 

Grab your 5 courses NOW!

Dependency Injection in .NET Core 2 with C#

.NET Engineer 5 Online Courses Bundle

Once you make a payment via PayPal, you will receive five Udemy coupon codes for the below courses: Dependency Injection in .NET Core, ASP.NET Core Identity, Unit Testing with xUnit.Net, TeamCity 2018, Atlasssian Bamboo, and Leadership for Beginners (six courses)!


DevOps Engineer Course Bundle

Once you pay via PayPal, you will receive five Udemy course coupons for the below courses. All coupons will be sent to the email address that is associated with your PayPal account. Courses include Grafana/Graphite, TeamCity 2018, Atlassian Bamboo, New Relic APM and Management and Leadership for Beginners.


TeamCity vs. Atlassian Bamboo


A comparison between TeamCity 2018 and Atlassian Bamboo!

One of the things I always do for the software development teams that I lead is introducing them to CI/CD, and setting up an effective Continuous Integration and Delivery system for them.

Often when it comes to implementing a CI/CD system there is a debate as to what CI/CD tool is the best to use? Some are fond of TeamCity while the others are a fan of Bamboo! And of course Jenkins has always had its lovers!

Since I have published two courses about TeamCity 2018 and Atlassian Bamboo, I would like to compare those two here and see which one would suit you better if you were to setup your CI/CD system.

When comparing tools such as TeamCity and Bamboo, we need to look at all aspects of running them rather than just looking at their features. In this article I will compare them in regards to their features, support, price and so forth.

TeamCity 2018:

TeamCity 2018 is NOT Open Source so if you use Open Source products you better think of a tool such as Jenkins or Sand Castle. To use TeamCity you need to buy a proper licence.

In terms of East Of Setup, TeamCity will get the TOP WINNER’s award amongst all other CI/CD tools. Installation of TeamCity, especially on Windows, is so straightforward and easy. Even installing TeamCity in a Highly Available and Highly Scalable manner is not difficult.

TeamCity also has the biggest number of Built-in Features amongst other CI/CD tools in the market! You can configure builds, define templates, define build triggers, configure dependencies etc.

TeamCity executes the build steps sequentially and it won’t run your build steps (e.g. compile and unit test) in parallel. This may not be ideal if you need to build, test and package big projects fast.

In this day and age many companies put their infrastructure on the cloud. If you use AWS, the good news is that TeamCity supports Cloud Build Agents on Amazon Web Services. This means that you will create a template for your Build Agents and TeamCity will launch the Build Agents based on those templates when needed.

Now let’s talk money!

If you have a small team which needs no more than three build agents, and won’t need support from JetBrains, then you can a Professional Server Licence, which is Free! With this licence you can have up to 100 Build Configurations, which for many small teams is more than enough!

If you need more build agents, you can pay $299 for each additional Build Agent and get Build Agent licence.

Bigger companies who need more build configurations, as well as official support from JetBrains, would have to buy an Etnerprise Licence which costs between $1,999 and $21,999!



Atlassian Bamboo:

Bamboo is NOT open source! You will get a Java package that can be virtually installed on any machine! The good thing is that since Bamboo is a Java application you will deal with the same application on different operating systems.

It is easy to install Bamboo especially on Windows, because as said before it is basically a Java application. TeamCity is a tad easier to setup comparing to Atlassian Bamboo especially when it comes to connecting to the database because Bamboo uses JDBC drivers which may be a bit unusual for most DevOps engineers and developers.

In terms of Built-in features Bamboo is behind TeamCity for sure! However the structure of your projects in Bamboo can be a lot more flexible! In TeamCity you only have “Build Steps” that execute sequentially, but in Bamboo you will have Projects, Steps, Jobs, and Tasks! This will give you a great deal of flexibility especially that Jobs can execute in parallel! That means while you run your unit tests you can run code inspection too! Or do many other things that can happen in Parallel, and save time!

Bamboo does support Cloud Build Agents aka Elastic Build Agents. However at the time of writing this blog post, Bamboo cannot be installed for High Availability and High Scalability.  You will need to install one instance of a Bamboo server and run a second instance as a backup! Nicht gut!

Bamboo has a diverse pricing options which you can see HERE. If you are a solo developer or a very small team you may use Local build agents and pay as little as $10. For more sophisticated setups you will pay something between $1100 to $126,500!

You can use both Atlassian Bamboo and TeamCity to build, package and deploy many different types of applications written in many different languages. However Bamboo is more favoured by Java developers whereas TeamCity is more favoured by .NET developers. Maybe because TeamCity comes with full built-in support for MSBuild and PowerShell! In saying that, virtually there is not any program that you cannot compile with both of these tools as long as there is a compiler for that program!

Can Techies be Leaders?

Although I am a techie myself one thing that I am passionate about is teaching management skills to new managers and talents both online and on-site.

One thing that I have learned myself through teaching management and mentoring talents is that transitioning from a tech person to a manager is quite difficult for most people. I often hear from my senior engineers that “I do not see management capabilities in myself”.  You may think that this may be a self esteem-related issue, which is somewhat correct, however we have to bear in mind that lack of confidence can rise from lack of knowledge and skills.

I have also witnessed that companies tend to promote technical staff (e.g. senior developers) to tech leadership positions. Although in rare cases it turns to be a successful experience, in most cases it does not end well.

Learn How To Become A Manager Now!

In fact my personal experience with this has been appalling! In 2005 when I was asked to manage a team for the first time, I was actually a senior developer who had many good ideas and was able to deliver work fast and with good quality. But I am not sure if it was enough for me to become a manager. From what I remember, the first few weeks went well but then issues started coming up. There were quite a few reasons for that and amongst them the most important one was my “Technical Mentality”!  A “Technical Mentality” is the thinking process of technical guys (e.g. engineers, developers etc) which is very black and white. 1 + 1 is always equal to 2 in a techie’s mind, and white is always white!  Plus, they tend to think that they are always right, and it is too hard to convince them otherwise!

So you may ask that “isn’t 1+1 equal to 2?”. Or you may ask “What do you mean that white is not always white?”.

The fact is that for good managers and for leaders, there is always a gray area and they tend to find a win-win solution when the disagreements arise. They are flexible and instead of insisting on their own opinion or solution, they listen actively and try to underestand where the other person comes from. For them a win-win situation is better than a triumph in a technical debate which  may damage the other person or even the entire team’s engagement, positive energy and moral.

You may not believe that how many tech guys I know that they dislike someone else just because the other person is not as good as they are in technical subjects! Unlike these types of techies, leaders never like or dislike any of their teammates for their strengths or weaknesses. A manager’s job is to focus on people’s strengths and help to improve their weaknesses. What I believe and  always say is that: If you do not love your team, you cannot do anything good for them!

But is this “techie mindset” fixable? My answer to this questions is “Hell yes!”.  A techie mindset is like a crooked tooth! What it needs is some force in the right direction and then over time it will go where it should go to! The force for tech people and new managers is courses and/or books, and direction comes from mentoring! Just like any other job, one can become a manager by learning the concepts and skills, then putting them in practice and making them a habit!

Setting up a TeamCity 2017 Cluster

It is very common for companies, teams and engineers to setup TeamCity in a way that TeamCity will not be able to unleash its real power!

The main two major .mistakes that are made in setting up a TeamCity-based continuous integration and delivery system are:

  • Putting the build agent software on TeamCity server (server hosting both TeamCity software and the build agent software).
  • Installing TeamCity as a single server.

Although TeamCity allows you to to install both TeamCity web application and its build agent service on the same computer it does not mean that it is a good idea! Only for learning purposes can someone install both TeamCity software and TeamCity build agent on the same machine otherwise this setup is not good and will cause headaches. So why should not you put both the TeamCity 2017 web site and its build agent on the same computer?

  • Because servers must be single responsible! One server should not have two responsibilities, which means your server must be either a TeamCity server or a Build Agent server.
  • Because build agents run the risk of getting corrupt and you may need to kill them at times! If this happen then you will have to kill your TeamCity server too!
  • Because you may want to take advantage of cloud build agents, in order to save $$$. If you set up your build agent on your server, you will not be able to terminate/stop your build agents when you do not use them.
  • You cannot scale out your build agents. The more concurrent builds you have the more build agents will be spun up by TeamCity but if you put the agent and the web-app on the same server this cannot be done.

Also setting up TeamCity as a single server does not seem to be a good idea for being used in production capacity as it will not be able to scale out. The figure below shows a typical (and not ideal) TeamCity setup:

SIngle-server setup of TeamCity

As you see the TeamCity server will be able to spin up multiple TeamCity Build Agents (if you setup cloud build agents) but it will not be able to scale out the actual TeamCity application. It will also not be highly available as a failure in the TeamCity Server will take down your CI/CD system.

In order to have a highly available and highly scalable TeamCity setup it is needed to use a centralised database such as SQL Server or MySQL so that all the projects, build configurations, templates etc can be shared amongst TeamCity servers.

Apart from a shared database, the data directory of the TeamCity servers have to be shared too so when you install the servers make sure you choose the same shared (e.g. network) location for all servers. You can also update the path of the data directory later via modifying the configuration file.

Copy of LearnTeamCity.pngScalable and Highly Available setup of TeamCity

Speaking in Amazon Web Services language, in the above diagram, our TeamCity Serves are part of an Auto Scaling group, which means that as stress and load goes up on the servers, AWS will spin up more and more TeamCity servers.

If you want your set up be highly available as well you will have to make sure that your Auto Scaling group stretches across multiple availability zones (physical locations) too.

To learn more about CI/CD with TeamCity 2017 and AWS CodeDeploy, you can see this online course. I have set a very special price on this course for my blog readers 🙂

Click to get 85% discounted online course about CI/CD with TeamCity 2017 and AWS CodeDeploy

TeamCity 2017: Build and deploy the modern way!

Grafana, Graphite and StatsD:Visualize your metrics!

Hey guys,

I have recently published two new courses on Udemy, and one of them has become a “Best Seller” so fast, in only two weeks! This course is interesting for a lot of DevOps engineers because monitoring and visualising the metrics of infrastructure, websites and applications is an absolute must-have skill for all DevOps engineers!

Developers also show interest in this course because the almighty Grafana-Graphite pair is an excellent tool for instrumentation and health check of application and websites.

In my course I have explained in over 25 lectures and 5.5 hours of videos that how you can extract and visual metrics from various sources whether it is supported by Grafana out of the box or not!

If you are an IT professional I highly recommend this course to you because based on my experience good instrumentation and having visibility on your systems metrics is what differs a good software system from the average ones!

Here is a coupon for my blog readers, which offers 80% discount!

Grafana and Graphite for DevOps Monitoring


Working with AWS S3 through C#

A while ago I needed to use AWS S3 (the Amazon’s cloud-based file storage) to store some files and then download them or get their listings through C#. As ironic as it sounds I noticed that there was no .NET implementation nor a documentation for S3 so I decided to create a file repository in C# which lets .NET developers access S3 programmatically.

Here is a rundown as to how you would work with AWS S3 through C#:

In order to use any APIs of Amazon Web Services (AWS) you will have to add the nugget package that is provided by Amazon. Simply bring up the Nuget Package Manager window and search for the keyword AWS. The first item in the search result is most likely AWS SDK for .NET which must be installed before you can access S3.



Once the SDK is installed we will have to find the properties of our S3 bucket and place it somewhere in web.config (or app.config) file. Normally these three properties of the S3 bucket is required in order to access it securely:


  1. Secret key
  2. Access key
  3. Region end point

These details will be provided to you by your cloud administrator. Here is a list of region end points that you can place in your configuration file (e.g. us-west-1)


Region name Region Endpoint Location constraint Protocol
US Standard * us-east-1 You can use one of the following two endpoints:

  • s3.amazonaws.com (Northern Virginia or Pacific Northwest)
  • s3-external-1.amazonaws.com (Northern Virginia only)
(none required) HTTP and HTTPS
US West (Oregon) region us-west-2 s3-us-west-2.amazonaws.com us-west-2 HTTP and HTTPS
US West (N. California) region us-west-1 s3-us-west-1.amazonaws.com us-west-1 HTTP and HTTPS
EU (Ireland) region eu-west-1 s3-eu-west-1.amazonaws.com EU or eu-west-1 HTTP and HTTPS
EU (Frankfurt) region eu-central-1 s3.eu-central-1.amazonaws.com eu-central-1 HTTP and HTTPS
Asia Pacific (Singapore) region ap-southeast-1 s3-ap-southeast-1.amazonaws.com ap-southeast-1 HTTP and HTTPS
Asia Pacific (Sydney) region ap-southeast-2 s3-ap-southeast-2.amazonaws.com ap-southeast-2 HTTP and HTTPS
Asia Pacific (Tokyo) region ap-northeast-1 s3-ap-northeast-1.amazonaws.com ap-northeast-1 HTTP and HTTPS
South America (Sao Paulo) region sa-east-1 s3-sa-east-1.amazonaws.com sa-east-1 HTTP and HTTPS


In order to avoid adding the secret key, access key and region endpoint to the <appSettings> part of your configuration file and to make this tool more organised I have created a configuration class for it. This configuration class will let you access the <configurationSection> element that is related to S3. To configure your app.config (or web.config) files you will have to add these <sectionGroup> and <section> elements to your configuration file:




type=Aref.S3.Lib.Strategies.S3FileRepositoryConfig, Aref.S3.LiballowLocation=true
allowDefinition=Everywhere />



class is inherited from ConfigurationSection class and has properties that map to some configuration elements of your .config file. A sample configuration for S3 is like this:











Note that <AspGuy> comes from the name property of <sectionGroup name=”AspGuy”> element. Also <S3Repository> tag comes from the name of <section> element. Each property of S3FileRepositoryConfig
is mapped to an attribute of <S3Repository> element.

Apart from SecretKey, AccessKey andBucketName you can specify a root directory name as well. This setting is there so you can begin accessing the S3 bucket from a specific folder rather than from its root, and obviously this setting is optional. For example imagine there is a bucket with the given folder structure:

  • Dir1
  • Dir1/Dir1_1
  • Dir1/Dir1_2

If you set the RootDir property to “” then when you call the GetSubDir methods of the S3 file repository if will return “Dir1” because Dir1 is the only top-level folder in the bucket. If you set the RootDir property to “Dir1” and then call the GetSubDirs method you will get two entries which are “Dir1_1” and “Dir1_2”.

Here is the code of the configuration class mentioned above:


For the repository class I have created an interface because of removing the dependency of clients (e.g. a web service that may need to use with various file storages) on S3. This will let you add your implementation of file system, FTP and other file storage types and use then through dependency injection. Here is the code of this interface:


In this interface:

  • Download: Downloads a file hosted on S3 to disk.
  • ChangeDir: Changes the current directory/folder to the given directory. If the new directory (relativePath parameter) starts with / then the path will be representing an absolute path (starting from the RootDir) otherwise it will be a relative path and will start from the current directory/folder.
  • GetFileNames: Retrieves the file names of the current folder
  • GetSubDirNames: Retrieves the name of folders in the current folder
  • AddFile: Uploads a file to S3
  • FileExists: Checks to see if a file is already on S3
  • DeleteFile: Deletes the file from S3

The implementation of these method are quiet simple using AWS SDK for .NET. The only tricky part is that S3 does not support folders. In fact in S3 everything is a key-value pair and the structure of entries is totally flat. What we do however is to use the forward slash character to represent folders and then we use this character as a delimiter to emulate a folder structure.





You can clone the repository of this code which is on GitHub to play with the code. Feel free to send a pull request if you want to improve the code. The GitHub repository is located at https://github.com/aussiearef/S3FileRepository