The annual go-to conference for developers (and everybody else) that just loves Microsoft developer eco system has been carried out. This time it was 48-hour only digital experience, at no cost. As previously, and despite being a full-blown virtual conference, a lot of new and interesting stuff has been presented. But what are the actual take-aways.

As tech people it is easy to be overwhelmed since many things looks cool. The excitement is big and to-do list of trying out all the new stuff suddenly grows even bigger, and boom suddenly the list covers all the topics presented. So, with this let try to pull out some interesting stuff without flooding the list. Of course you should also have a look at this official dotnet blog, the channel 9 Build videos and Microsoft news page

Windows Terminal: This one you should definitely give a try; a lot of features and settings possibilities. It can be download from the Microsoft Store or from the GitHub releases page. Also make sure to check out this page for some cool modifications of the terminal

Winget: The first official (I think) Windows Package Manager for Windows, though in preview

Blazor WebAssembly: An open sourced and cross-platform web UI framework for building single-page apps using .NET and C# instead of JavaScript. Even though I prefer using JavaScript and frameworks like VueJS this one looks promising. It is also worth mentioning that now it is fully released and production ready

C# 9: Improved pattern matching, immutability with Init-only properties, with-expressions, top-levels program are just some of the upcoming features

Application Insights & Azure Monitor: Extended support for containers, Azure Monitor for Storage & Cosmos DB

Teams: Integrations with Power Platform and extensions for visual studio and visual studio code are coming.

Microsoft Lists: A to-do app to rule them all. To-do apps never gets boring.

Background

In Azure DevOps there are kind of two ways of setting up pipelines (previously also called builds). One can use the classic editor or the yaml approach. The classic editor is more visual where tasks can be added and modified. A typical setup can look something like this (non dotnet core):

By clicking in the right top corner "View YAML" one can see the content of this setup in a yaml format. So basically this "classic" setup is also yaml based behind the scenes.

Instead of using the classical way, one can use yaml all the way. By this I mean that the yaml file will be part of the source checked in. By using one of the YAML variants below a pretty default azure-pipelines.yml is generated:

In most of my projects the auto generated yaml file is not sufficent. I usually need more tasks where gitversion is one of them. My azure-pipelines.yml often looks like this one. Behind the scenes I'm also using GitFlow

trigger:
- develop
- release/*
- feature/*
- bugfix/*
- hotfix/*
 -refs/tags/*

pool:
  name: Default

variables:
  buildConfiguration: 'Release'

steps:
- task: GitVersion@4
  displayName: 'GitVersion'
  inputs:
    updateAssemblyInfo: true
    preferBundledVersion: false

- script: echo %Action%%BuildVersion%
  displayName: 'Set build version'
  env:
    Action: '##vso[build.updatebuildnumber]'
    BuildVersion: $(GitVersion.SemVer)

- task: DotNetCoreCLI@2
  displayName: 'dotnet restore'
  inputs:
    command: 'restore'
    projects: '**/*.csproj'

- task: DotNetCoreCLI@2
  displayName: 'dotnet build $(buildConfiguration)'
  inputs:
    command: 'build'
    projects: '**/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  displayName: 'dotnet test $(buildConfiguration)'
  inputs:
    command: 'test'
    projects: '**/*Tests/*.csproj'
    arguments: '--configuration $(buildConfiguration)'

- task: DotNetCoreCLI@2
  displayName: 'dotnet publish $(buildConfiguration)'
  inputs:
    command: 'publish'
    publishWebProjects: false
    arguments: '--configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)'
    zipAfterPublish: True

- task: CopyPublishBuildArtifacts@1
  inputs:
    Contents: '$(Build.ArtifactStagingDirectory)'
    ArtifactName: 'drop'
    ArtifactType: Container

A successful build that is nicely versioned looks like the one below.

One small note about the pool agent used. The Default one is Windows based build agent, and that is because using an Ubuntu Hosted agent results in System.BadImageFormatException: Method has no body. A related issue can also be found on github

Resources

• https://docs.microsoft.com/en-us/azure/devops/pipelines/yaml-schema?view=azure-devops&tabs=example
• https://docs.microsoft.com/en-us/azure/devops/pipelines/languages/dotnet-core?view=azure-devops

Transaction support in MongoDB

First things first; a transaction is a unit of work that should be treated as "a whole." It has to either happen in full or not at all. Transaction support in relational databases likes MSSQL or Oracle Databases have been around for a while. The case for NoSql databases though, is not the exactly same, well until now. As the first NoSql database, MongoDB (and you may correct me if I'm wrong) has as of version 4.0 implemented support for multi-document ACID transactions. Just to make clear, MongoDB has always supported ACID transactions in a single document, and you may also read about early days of DynamoDB and its introduction to transactions with some limitations. For most of the cases and for big number of applications single document ACID has proven to be sufficient. For those cases that needed some kind of transaction control, it was implemented manually.

Usage of transactions are in many cases related to the finance domain and are often seen in examples with money being transferred between accounts. If withdrawing one account fails, then other operations involving other accounts should be aborted as well. For the money transfer one can argue that by putting everything in one document, the case can easily be solved without transactions. So, when do we need transactions?

Well, let’s have a look into CQRS and EventSourcing sphere. If you are not familiar with CQRS or EventSourcing you can have a look at Martin Fowlers official definition. If you find CQRS interesting you also may want to look into this collection of different resources related to the subject. Practicing CQRS usually means that commands and queries are treated separately, which in order implies different databases; one for persisting the outcome of commands(events), and one for persisting an optimized read model (current snapshot). Reasons for having two different storages could be optimizations, separation of concerns, etc.

With great choice comes also great responsibilities, and one of them is consistency. If no attention is paid to this subject, one may end up having stale data in the read model, also referred to eventual consistency. As a side note; many NoSQL databases embraced an eventual consistency approach, while MongoDB supported a strong consistency model for single document.

If dealing with eventual consistency is not an option, one must make sure that any operation made on the event storage happens in sync with operation made on the read storage. In other words, the operations must occur in a single transaction.

The setup

For this scenario I'm going to use CQRSLite, which is a small library that helps creating CQRS and Eventsourcing applications in C#. I'll implement a MongoEventStore that handles events and updates the readmodel in one transaction. The business case for the purpose is a simple user registration api, which supports user registration and activation of the user account.

First of all, I need to setup the mongo replica set, because transasctions can only run replica set. Trying to run transactions on a standalone mongod instance will throw the following exception: MongoError: Transaction numbers are only allowed on a replica set member or mongos. As I already have monodb installed on my computer, I'll just add a replica set to it. For my setup I'm using mongodb v.4.0.9. To avoid tampering with some of the default mongo port that is 27017, I just choose another ranmdom ports

  mongod --replSet rs0 --dbpath c:\data\rs1 --port 37017
  mongod --replSet rs0 --dbpath c:\data\rs2 --port 37018 
  mongod --replSet rs0 --dbpath c:\data\rs3 --port 37019

Then I log into the mongod process on port 37017, which will be the primary, and configure the replica set. More about replica set configuration and usage here here:

mongo --port 37017
config = {
	_id: "rs0",
	members: [
	{_id: 0, host: "localhost:37017"},
	{_id: 1, host: "localhost:37018"},
	{_id: 2, host: "localhost:37019"}
	]
}
rs.initiate(config)

If you instead want to use docker for running the replica set there are plenty of tutorials on how to do that.

When working with one mongod instance, creation of the database and the collections can be done on runtime. On the other hand, working with transactions this is not allowed and the following exception will be thrown. So, make sure this is done in a script or similar up front. In a production environment this should even be part of a CI/CD process.

.

For now, I'll just run the following command to set up my database and collections:

use usersystem
db.createCollection("events")
db.createCollection("userreadmodel")

To be able to use transactions I need an IClientSessionHandle object, and this is the object I need to use for the collections I want to make sure are part of the transaction. To achieve that I create my own interface; IMongoContext holding the necessary interfaces.

public interface IMongoDbContext
{
  IMongoDatabase Database { get; }
  IClientSessionHandle Session { get; }
  Task<IClientSessionHandle> StartSession(CancellationToken cancellactionToken = default);
}

Then I register IMongoContext as singleton and can make use of the same session accross different handler classes that are part of the flow.

public static IServiceCollection RegisterServices(this IServiceCollection services)
{
   services.AddSingleton<IMongoDbContext>(x => new MongoDbContext());
.....
}

In the MongoDbEventStore I make sure I have injected IMongoDbContext so I can start a session and a transaction. For the transactionoptions I use ReadConcern.Snapshot, ReadPreference.Primary and WriteConcern.WMarjority. More about read concerns here and write concerns here

public MongoDbEventStore(IEventPublisher publisher, IMongoDbContext mongoDbContext)
{
  _publisher = publisher;
  _mongoDbContext = mongoDbContext;
  _events = _mongoDbContext.Database.GetCollection<EventData>(EventsCollection);
}

public async Task Save(IEnumerable<IEvent> events, CancellationToken cancellationToken = default)
{
   using (var session = await _mongoDbContext.StartSession(cancellationToken))
   {
      var options = new TransactionOptions(ReadConcern.Snapshot, ReadPreference.Primary, WriteConcern.WMajority);
      session.StartTransaction(options);
      try
      {
          var bulkOps = new List<WriteModel<EventData>>();
          foreach (var @event in events)
          { 
             var eventData = new EventData
             {
                 Id = Guid.NewGuid(),
                 StreamId = @event.Id,
                 TimeStamp = @event.TimeStamp,
                 AssemblyQualifiedName = @event.GetType().AssemblyQualifiedName,
                 PayLoad = @event
             };
             bulkOps.Add(new InsertOneModel<EventData>(eventData));
             await _publisher.Publish(@event, cancellationToken);
          }
          await _events.BulkWriteAsync(session, bulkOps).ConfigureAwait(false);
          await session.CommitTransactionAsync(cancellationToken).ConfigureAwait(false);
        }
        catch (Exception exp)
        {
           session.AbortTransaction(cancellationToken);
           throw exp;
        }
    }
}

By publishing events from MongoDbEventStore, we can have any numbers of listeners to grab the events and handle them the best way needed. One of the handlers that we need in order to update the readmodel, is a UserReadModelEventHandler. This class handles only the readmodel and by injecting IMongoContext to its ctor, we are able to get the session that is needed when invoking the InsertOneAsync() to make sure both collections are updated within the same transaction. The transaction is completed when writing to events collection and readmodel collection has succeeded.

By looking back into the user registration api, the flow should be as follow:

• User is registered by posting a request to "/user" endpoint. The response is the user id
• By using the user id and doing a put request to "user/{userid}/activate" the user is activated

If we then take a look into the database, using MongoDb Compass, we'll find two events, one for registrating the user and one for activating the account. By looking at the version property we can see that they have occurred in proper order.

Also looking into the userreadmodel we can see that there is one document with the current state of the user.

The entire solution is available on my github

Considerations

For this demo I have used a naive approach to implement a mongodbeventstore. By this, I mean that one event occurred on the aggregate results in one document in the eventstore. With many events on the aggregate this could potentially slow down the loading of the aggregate. Another approach to consider when there potentially could be many events per commit, is to store the events as a collection within the same commit. This way you will end up having less documents for the same aggregate, which in turn will speed up the event replay time.

Be aware of

• Database and collections must be created upfront, otherwise an error message is thrown.
• Transactions are not supported with shards in version 4.0. Support is scheduled for version 4.2
• Transactuins cannot run on standalone instances of mondodb.
• There is a an additional cost in using transactions, so carefully carry out your transactions
• As a best practice, no more than 1,000 documents should be modified within a transaction.

Resources used

• https://en.wikipedia.org/wiki/Database_transaction
• https://www.infoq.com/articles/MarkLogic-NoSQL-with-Transactions
• https://martinfowler.com/bliki/CQRS.html
• https://github.com/gautema/CQRSlite
• https://www.mongodb.com/transactions
• https://www.mongodb.com/blog/post/working-with-mongodb-transactions-with-c-and-the-net-framework
• https://blog.yugabyte.com/nosql-databases-becoming-transactional-mongodb-dynamodb-faunadb-cosmosdb/

Protecting a site using Microsoft account

Using your Microsoft account to protect a website or a web api in Azure has become quite a breeze. By following these few steps, your site is protected in minutes:

• Create a free azure account
• Create and deploy your web/api site in Azure portal
• Navigate to your Site -> Authentication / Authorization in Azure portal and enable App Service Authentication, select Log in with Microsoft Account, save and off you go. Your newly site is authenticated and protected.

Potecting a site using Azure Ad

Now your site is protected and you are happy, but then new requirements starts to rise. E.g. you want to enable your site to other users with minimum amount of effort. You fool around a bit in Azure portal, StackOverflow and Google, and figure our that Azure Active Directory is a suitable way to go. You follow these steps and you have an Azure Ad.

To be able to use credentials to log in on the site, the app also needs to be registered in the Azure AD -> App registrations.

All new users that are supposed to have access to the website/app must be granted access. This can be done from the app it self, using one of the approaches listed below:

1. Azure Active Directory -> App registrations -> select the app -> Settings -> Required permissions and finally click Grant permissions -> Enterprise applications
2. Azure Active Directory -> select the app -> Users and groups -> Add users -> find the user and click select

My experience is that approach #1 does not always work as intended, so I just prefer to use the second approach.

The applications is now protected, and new users can be added on the go. By selecting the free tier for Azure AD, quite a few users(500K objects as MS calls them) can be added.

If the application is all off type ASP.Net MVC, you have at this moment achieved to protect your site and can live happily ever after. But if it is not, and it is more off the new modern kind, say a microservice-ish, and uses a web api to get som additional data, then the entire chain is not secured. E.g. there is an app and a web api. The app could be MVC or any may a more modern SPA app, created with Vue or React or whatever floats your boat and it interacts with the web api to get data. More or less de-facto way of building apps today.

The current setup with just protecting the app is illustrated below. The user interacts with app, and if it is the first time the user hits the url for the app, the Azure AD protection mechanism wakens up and the user is redirected to Azure AD log on page. The user provides credentials, and if all good, the user is then redirected back to the app uri. The app in turns uses the api to get data, which in turns uses some kind of storage.

Since the api is not protected the user, as smart as he or she is, can also get the data directly from the api. This also means that anybody else can fetch the data directly, and this is a scenario that we don't want to happen. To prevent the api from being exposed to the entire world, we start by protecting it using the same approach as we did for the app. The preferred scenario is as illustrated below:

Shortly described, the entire flow starts as previously by authenticating before using the app, and then in turn for the app to use the api, the app must authenticate against api to get the data. This can be achieved with two different approaches:

Using ClientCredential

As always the first thing I do when I want to use something I haven't used before, I google it; and for sure there was github repo example using clientCredentials. I cloned the repo, replaced settings in the App.Config, with my settings and it all worked as expected.

The key method to use to get the token from Azure Ad is the AcquireTokenAsync(string resource, ClientCredential clientCredential). So, I start off by providing the resource param. The resource could either be the api endpoint or the ApplicationID. I prefer to use the Application ID.

The second param is ClientCredential. By using the ClientCredential I have to provide the clientId, and appKey for the Web app accessing the Api. The clientId, also known as Appplication ID can be found be navigating to Azure Active Directory -> App registrations -> select your app -> Application ID. The AppKey must be generated for the first usage. When still on the Registered App window, navigate to Settings -> Keys -> add new key name in the description and click save. Remember to store the value, as it will remain hidden for ever. If you forget your key value, just generate new secret.

To sum it up this is the code snippet that retrieves the token:

private static async Task<string> GetTokenWithClientCredential()
{
    var authority = string.Format(CultureInfo.InvariantCulture, aadInstance, tenant);
    var authContext = new AuthenticationContext(authority);
    var clientCredential = new ClientCredential(clientId, appKey);

    var result = await authContext.AcquireTokenAsync(todoListResourceId, clientCredential);
    return result.AccessToken;
}

Using UserPasswordCredential

So, again, I do the magic with google, and woop, there is another github repo demostrating the usage of authenticating with Azure Ad credentials using the UserPasswordCredential. I clone the repo, run it and get the following:

Doing some research, I figure out that I'm running AzureAD V2, while this example is based on AzureAD V1. So I get curious whether it is possibile to obtain the token with user credentials also with AAD V2. Reading the exception message it clearly states that one of the following parameters are missing; client assertion or client secret and some more googling also gives indication that the client secret is missing. So how am I suppose to provide the client secret along with user credential? Well maybe just do a regular post. Before I do that I choose to inspect the request done with AcquireTokenAsync() using fiddler, and correctly client_secret is not provided:

Since I could not find a way of providing client secret to the AcquireTokenAsync() method I'll just manually created the url and do a regular PostAsync() using the HttpClient() class:

var azureAdEndpoint = new Uri(authority + "/oauth2/token");
var urlEncodedContent = new FormUrlEncodedContent(new[]
{
   new KeyValuePair<string, string>("grant_type", "password"),
   new KeyValuePair<string, string>("scope", "openid"),
   new KeyValuePair<string, string>("resource", todoListResourceId),
   new KeyValuePair<string, string>("client_id", todoListResourceId), //using the api client id
   new KeyValuePair<string, string>("username", _user),
   new KeyValuePair<string, string>("password", _password),
   new KeyValuePair<string, string>("client_secret", _clientSecret),
});

var result = await httpClient.PostAsync(azureAdEndpoint, urlEncodedContent);
{
   var content = await result.Content.ReadAsStringAsync();
   var authResult = JsonConvert.DeserializeObject<dynamic>(content);
   return authResult.access_token;
}

As expected this provides me the correct token, that I can use from my web app to get data from my api.

The source code can be found here

Summary

In this post I have looked into how to protect a web app and api hosted in Azure, using Azure AD v2. The web app is protected using the regular AAD Authentication mechanism that interactively asks the user for the credential, while the web app silently or non-interactively authenticates against the api using the provided clientcredentials or userpasswordcredentials. Protecting a webapplication using this approach is not very dyanmic, and is maybe more suitable for existing web applications the needs to be migrated to Azure with little effort. If you on the other side need a more dynamic and flexible authentication, you should consider solutions like identityserver or implementing your own identity management using ASP.Net core identity

Note

At the moment writting this post, April. 4th, Microsoft has updated there git repo example with a newer version supporting Azure AD v2.0, and using Graph API

Resources used in this post:

https://github.com/Azure-Samples/active-directory-dotnet-native-headless
https://github.com/Azure-Samples/active-directory-dotnet-daemon
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d54c668f-d8e3-4662-b124-d9abc3176c8c/http-post-body-parameters-to-get-oauth2-token?forum=azurelogicapps
https://carldesouza.com/httpclient-getasync-postasync-sendasync-c/
https://github.com/AzureAD/azure-activedirectory-library-for-ruby/issues/57

Having small kids also means that I can do all the things I missed in my childhood; like going to a wildlife park. This time, my family and I have decided take the trip to Kristiansand Zoo and amusement park. The park is located in the southern part of Norway, and living in Oslo, this means a road trip for 4 - 5 hours. Well, in theory, yes, but in real life, no. After 2 - 3 hours of driving different kind of noises start to appear from the back seat, and suddenly all kind of nagging started; need for toilet, not fun to just drive and drive, hungry, thirsty and so on. And no, I don’t have any back-seat entertainment set up, but will for sure consider one after this journey.

Accommodation

After about 6 hours we arrived in Kristiansand, and within some minutes with great help from google maps we found the hotel for the night. This hotel is probably the most convenient way to stay when visiting the park, as it is literally situated beside the entrance.

The hotel is named and shaped like the famous vessel Noah's Ark. When booking tickets online, one can also book accommodation in this hotel, which is highly advice. The theme in the hotel is all about animals which seems to be quite appreciated by the kids. But despite this being a god stay, there are also other different god hotels or motels just a search away. Take a look on sites like booking.com.

Inside the hotel there are different facilities like a workout room, a playroom for the kids, a big restaurant on the ground floor, as well as a big lounge on the same floor. And probably something more that I missed.

The dinner for the evening was a buffet, containing seafood, different kind of meat, vegetables and desserts. Overall, well prepared and good variations in the food.

Despite having a great meal in front of you, the most important thing for the evening was of course the playroom, speaking from a kid's point of view. So, after consuming big amount of delicious pudding and cookies nothing else was more logical than running away and play. Since the playroom was across the lounge it was no biggie for us adults, just sitting down and relaxing while kids was exploring all the fun.

The exploration

Moving on to the next day, after a god night sleep, followed up by a great breakfast, what first caught our sight from the room, was the enormous queue of people waiting to get inside the park. Obviously, we were not the only ones to explore the park that day.

Luckily, there were many entrances and a very efficient staff, so after some short amount of time we were inside. The entire park is organized by themes or attractions. E.g. the animals are situated on one side of the park, while the aqua land and "Kardemomme by" is situated on the other side. You can read more about this on the sites official map. We started the journey in the Captain Sabertooth World moving on to the "Kardemomme by".

And honestly speaking, the world of Captain Sabertooth wasn't much to see, nor do. Neither did our kids found it especially interesting. Probably here as well, one should follow the scheduled activities.

Then some steps away there it was, The Cardmoom Town. Approaching it from "hill" side, it opened up for some great shoots as well. The fun thing about the Cardamom Town is actually to be there, because almost every child in Norway has heard about it through the book When the Robbers Came to Cardamom Town. Being able to experience everything in miniature, was a huge success among the kids. Maybe this was also the biggest highlight of the exploration.

The animals

According to the website there are 135 different species in the zoo, and if you are a quick explorer you will probably be able to see them all. Slightly hurrying from one booth to the other we noticed that many of the animals seems to be quite lazy, most of the time just sitting or lying around. However, if you are looking for a bit more action, you should try to follow the scheduled activities set up by the staff in the park.

So, to sum it all up; the excursion was great, and it is highly recommended to visit the park, especially if you have small kids. If you want to get must out if it, you should plan your trip slightly more than what we did. And, it is also an option to get to Kristiansand Airport, Kjevik by plane from probably all of the bigger cities in Norway.

Have fun!

Note: All pictures in this post are taken by me, and thereby copyrighted by me. As long as you keep the copyright information, and keep the reference to this blog you are free to use the pictures in any way. If you would like to get any of these pictures in native, high resolution, please contact me.

Configuring Octopus Deploy

1. Start by adding an new external feed. Navigate to** Library -> External feeds -> Add feed**. I’m naming the feed for** “TeamCity Package feed”, and the url is http://localhost:84/guestAuth/app/nuget/v1/FeedService.svc**. As you maybe have noticed this is the feed we enabled earlier in TeamCity, and this is the feed we are going to use to fetch artifacts from TeamCity and the Octo project. For the sake of simplicity I’m using the guest login, but you could also have used an authenticated user, provided with Username and Password in the input fields below.

2. Add a new default lifecycle; Library -> Add lifecycle.

3. Now move on to Environments and add two environments; Test and **Prod. **In Octopus, an environmentis a group of machines that you will deploy to at the same time; common examples of environments are Test, Acceptance, Staging or Production. In bigger developer environments it is normal to let one machine represent one environment. In this example we are using both environments on the same machine.

4. Add one Deployment target for the Test environment and one for the Prod environment. For the Test environment add the following:

• Display name: web-test-01
• Environments: Test
• Roles: db-server, web-server
• Style: Listeting Tentacle
• Thumbprint: You can find the thumbprint in the Tentacle Manger
• Tentacle URL:** https://localhost:10933 (this is the default suggestion I’m using, but this could be something else in your installation)**

For the Dev environment add the following Deployment Target:

• Display name: web-prod-01
• Environments: Prod
• Roles: db-server, web-server
• Style: Listeting Tentacle
• Thumbprint: You can find the thumbprint in the Tentacle Manger
• Tentacle URL:** https://localhost:10933 (this is the default suggestion I’m using, but this could be something else in your installation)**

5. Go to the Projects menu and add new Project. I’m calling my project for Octo. Add the following variables to the project:

6. Navigate to Process and add the step “Deploy a Nuget package” and call it for “Deploy Web site”. Than add the following parameters:

• Runs on target roles: web-server and** db-server**.
• Nuget feed: TeamCity Package feed
• NuGet package ID: Octo
• Download options: The first option
• Install to: #{CustomInstallationDir}
• Purge: Checked
• Configuration Variables: Checked
• XML transforms: Checked
• Web Site: Checked
• Web Site name: #{CustomWebSiteName}
• Relative home directory: Leave empty
• Application pool name: #{CustomWebSiteName}
• .NET CLR version: v4.0
• Identity: Application Pool Identity
• Bindings: - Protocol: Http
• Port: #{CustomWebSitePort}
• IP Address: 127.0.0.1
• Host name: #{CustomWebSiteName}
• Authentication modes:Cheked (Enable Anonymous authentication)
• Environments: Test, Prod

7. At this moment the configuration part is finished. You can make some changes to the code and push the commits to the remote repo. The build should automatically start in TeamCity and the deployment should be processed in the Octopus. If everything goes green the deployment is working as expected. Another way to verify the deployment, is by opening the wwwroot directory. There you should find two new folders; octo-prod and octo-test.** **The folders should contain a mvc webapp which also include web.config file. In the config files there is a connection string with environmentname in the database name. The assemblies should also have been versioned.

Configuring TeamCity

1. Enable Nuget Feed in TeamCity: Administration -> Nuget. Enable both the Authenticated feed and the Public feed. To enable the public feed the Guest user login must be allowed. Also get the lates Nuget version.

2. Download and install Octopus TeamCity plugin. Stop TeamCity services, and move your Octopus plugin to the following directory:** “D:\TeamCity\plugins”. **Now start your TeamCity services again, and the plugin will be installed automatic.

3. Now create a user on Bitbucket and create a Git repository. We are naming it for Octo.

4. Create a Web Application (I’,m using MVC) in Visual Studio based on .NET Framework 4.6 and map it with your Bitbucket repo. Add the unit test project to it as well. Following the instructions provided in Bitbucket should make this a quite easy process.

bitbucket setup

5. In this example we will be using one git branch, master, that will be build and deployed once, but promoted to different environments. This is where Octopus Deploy have it strengths.

6. Start by creating a new project in TeamCity, called Octo.  Now add VCS root to that project. Surprisingly enough we will be using the newly created repo from Bitbucket; octo.git

teamcity config

teamcity config

7. Add two build configurations to your TeamCity Octo project, one for building the project and creating artifacts, and one for deploying the artifacts to Octopus. I’m naming my builds for “100 – Master CI” and** “110 – Master Deploy website”**. The naming convention is inspired by Roy Osherove talk about beautiful builds

8. Move to your “100 – Master CI” build configuration and three parameters: system.MajorVersion.Master, system.MinorVersion.Master and **system.PathVersion.Master. **These parameters will be used to create a buildnumber.

teamcity config

9. Under Build Features add a new build feature: “Assembly Info patcher”. Use the parameters created in prevous step. Use the same format in all three input fields:** %system.MajorVersion.Master%.%system.MinorVersion.Master%.%system.PatchVersion.Master%.%build.counter%. Add this inputstring in the “Build number format” field underneath “General Settings”** menu as well.

teamcity config

10. Create** VCS trigger** underneath “Triggers” menu. Whenever a push is performed on the git repo this is the trigger that starts the build process.

teamcity config

11. Attach the created VCS Root to the configuration.

12. Now add three build steps to the configuration; “01 – Package restore”, “02 – Build solution” and** “03 – Create Nuget Package”.** Use the options provided in the screen dump below. In the build step 3 there is section for Octopus. This is actually the plugin we installed earlier.

teamcity config

13. Open the Visual Studio project directory and add a new empty file called Octo.nuspec. A .nuspec file is a manifest that uses XML to describe a package and must exist, otherwise no artifacts will be created. Open the file and add lines as proposed:

teamcity config

14. Open your Visual Studio project, navigate to “Manage NuGet Packages” and add OctoPack to your solution. Push all your solution changes to remote.

visual studio octo nuget pack

15. At this moment You should have a valid build setup. You can now try to run, and hopefully you will see that some artifacts are generated.

16. Now open  “110 – Master Deploy website” configuration and navigate to “General Settings”.  In** “Build number format”** field add the following input: %dep.Octo_100MasterCI.build.number%

17. Underneath “Triggers” menu add “Finish Build Trigger” trigger and use build configuration “Octo :: 100 – Master – CI”. This is the previous build configuration that will start this one.

18. Underneath “Dependencies” add one Snapshot Dependency and one Artifact Dependency where both depends  on **100 – Master – CI”. ** In the Artifacts rules field for Artifact Dependency add the following *.%build.number%.nupkg

19. For this build configuration there is only one build step. Add** “OctopusDeploy: Create release”** as Runner type. In the Octopus URL add url to the Octopus Web installed in previous step (should be localhost:82). When asked for the API key, it can be generated in the Octopus web portal; admin -> profile -> API Keys. In the “Deploy to” field add Test, as we will create test environment in Octopus that this deploy will use. As additional command line arguments add the following:** –packageversion=%build.number%**

teamcity config

20. At this moment TeamCity should be properly configured. You can now try to add some changes to your code, push the changes to Bitbucket. The build should automatically start after some time. Both build configuration will run, but the last one, “110 – Master Deploy website” will not do much since the Octopus Server is not set up. So go ahead and start configuring the Octopus Server.

Installing and setting up Octopus Deploy

This is the 3. part of Building and deploying with TeamCity and Octopus Deploy. In the previous part we installed TeamCity. Now we are going to install Octopus Deploy. Octopus Deploy consist of two install files; one for server and one for tentacles

1. Start by creating a new Octopus database and associate the login we previously created with the Octopus database (in the same way we did with TeamCity). Download Octopus Server and run the file. The proposed settings are just fine. Check for “Start a free trial” when You approach the license step. As with TeamCity use a separate path for storing configuration files. I’m using drive D here as well. D:\Octopus.

octopus setup

2. Choose the newly created database, and use the same login to access the database.

octopus setup

3. Define the port and a virtual directory. Here I’m using /octopus as virtual directory but it is not necessary

octopus setup

4. Choose your preferred authentication mode. I’m using “Username/password stored in Octopus”. Create an admin user and finish the installation. Hopefully everything was OK. Octopus have now installed a desktop app: “Octopus Manger” where you can find some status information about your server. Now you can login to the server web app.

octopus setup

Octopus Tentacle

1. Start by downloading the setup file for the tentacle, and run the .msi. Here as well we will be using own directory for the tentacle configuration: “D:\OctopusTentacle”

tentacle setup

**2. **Choose “Listening Tentacle” as communication style, and add the certificate key. The certificate key can be found in Octopus Server web application under Configuration -> Certificates

tentacle setup

3. Finish your installation. The next step is to configure TeamCity and Octopus to build and deploy when checking in code

Installing and setting up TeamCity

1. Start by downloading TeamCity and start the installation. The proposed suggestions in the setup wizard are just fine:

2. Choose your path for Data Directory. Data Directory is used for storing configuration settings. I prefer to use a different path than the one where the program files are installed. In my case I’m using folder on D disk: D:\TeamCity.

3. Select preferred database type. If you want to get up and running fast, You can select the built in database **HSQLDB. **The built in internal database is not recommended for production use. In my setup I’m using Microsoft SQL Server 2014. Initially I tried to use SQL Express, but faced some issues and I didn’t bother spending time on solving them as I already had the full version of MsSql installed. Though I came across a blog that handles that issue, if SQL Express is your only option.

No create a database, call it TeamCity, and create a Sql login. Associate the newly crated login with TeamCity database. We will be using this login to talk with the database:

4. Now proceed with your TeamCity wizzard. At this moment TC is asking for a MS SQL Server JDBC Driver. Download the file from Microsoft and place it in D:\TeamCity\lib\jdbc directory, and click the refresh button.

5. If everything is ok, You have reached the final step which are to accept the license agreement and create a new user. Do that and You have finished the TeamCity installation. The next step is to install Octopus Deploy.

TeamCity and Octopus Deploy

There have been a lot of writings about continuous integration and  automated deploy and why “doing it”. This post is not about that, but rather about what does it take to set up the entire automated flow from the step when the code is checked into the SC to the final step when the software is deployed. The tools I will be using are TeamCity and Octopus Deploy, and the application is a web application written in C# with Visual Studio. The code will be stored in a git repo hosted in BitBucket. The entire set up will be done on one machine and the OS used is windows 10.

Reasons for choosing TeamCity, Octo, and BitBucket are quite simple; all of them provide free use for single users or small teams, they have great documentation and are pretty easy to start working with. Now let’s get started:

Installing and setting up TeamCity (part 2)

Installing and setting up Octopus Deploy (part 3)

Configuring TeamCity (part 4)

Configuring Octopus Deploy (part 5)

Tools used:

• TeamCity 9.1.5
• Octopus Server 3.2.22
• Octopus Tentacle 3.2.22
• TeamCity plugin 3.2.0.51
• Microsoft SQL Server 2014Visual Studio 2013 Premium