Recently Microsoft announced a rebranding of Visual Studio Team Services (VSTS) to Azure DevOps and as a big fan of Azure, I wanted to check out if the changes were just a new name or if it’d progressed to be a little more welcoming.
I say this because as someone with limited experience using VSTS, I always found it to be a little intimidating so tended to use simpler services like App Center for building my apps and Trello for my Kanban boards. I hoped that the change would include some UI enhancements that could help me ease into DevOps rather than being thrown into the deep end.
Thankfully the team has done some fantastic work in making Azure DevOps easier to get started with and I’ve now adopted it for managing my personal long term project.
In this post, I’m going to discuss how and most importantly why I’ve configured Azure DevOps to allow me to have confidence in the code I’m writing.
In this post, I’m going to discuss how and most importantly why I’ve configured Azure DevOps to allow me to have confidence in the code I’m writing.
One huge solution to rule them!
The project I’m working on is big, or at least it’s going to be massive. Right now its just a minimum viable product and it contains 17 projects, which I originally put into a single Git repository. This worked well for the beginning of the project but as I started to add more and more projects it became difficult to keep things separate.
It’s for this reason that I decided to create two separate solutions to make a clear separation of concerns. Ultimately I’ll probably end up splitting up Lighting Core Solution further as the project develops but for now I think two solutions provides me with enough separation.
Smaller Solutions
Having two separate solutions rather than one beast makes my life significantly easier for ensuring that the Lighting Core code doesn’t become too sticky with my UI and vice-versa. It does, however, cause me some difficulties in how I should reference the dependancies as I don’t have an easy way to ensure that the UI project has all the code required to build. To solve this, I went ahead and moved all my code in Azure DevOps as a stepping stone towards fully embracing the tool.
Private Nuget Feed
With all the code hosted in Azure DevOps I have a one-stop shop for my projects development.
I went ahead and defined build processes and hooked them up so they’d be triggered everytime I pushed code to the master branch.
The build steps is very simple. I restore packages, build and then pack up the DLLs ready for release.
I’ve defined separate pack tasks for each project that I wanted to turn into a Nuget package. This task handles packaging up the results from the build ready for releasing either publicly or privately.
I’ve then defined the most basic release pipeline possible to take the results of the build pipeline and push to Nuget.
Because I’m releasing the packages privately, I host them in Azure DevOps and can access them in Visual Studio with minimal configuration required!
Wrapping up
This blog post covers at a very high-level how I’ve gone about setting up the basics of a continuous integration and deployment system for my pet project. If you want to learn how you can also configure your own CI/CD system then checkout the great tutorial over at Microsoft Docs.
It’s that time of year again where we all ask ourselves “should I install this beta software on my devices and risk my development setup?”. If you’ve only one iPhone and Mac then it can be difficult to decide when it’s the right time to install the latest and greatest offerings from Apple, for fear of breaking your development environment.
This year I’ve not needed to be so worried about breaking my environment as my current projects see me developing more with ASP.NET and Swift than Xamarin, so I went ahead and downloaded both iOS 12 and macOS 10.14 as soon as I could.
How does it run?
First impressions of running macOS Mojave and Xamarin are better than expected! I fired up Visual Studio for Mac and opened the workshop myself and Robin-Manuel Thiel created to see if I could get the iOS app to build using Xcode 9. The good news is that it works without any modification assuming you had a working setup before upgrading.
With that said, I have experienced some crashes with resizing VS4Mac but issues are expected at this stage.
Advice
If you can avoid it, don’t update just yet if your day-to-day development requires the Xamarin tooling to work. The Xamarin engineers will need some time to test and ensure things work properly as they too have only just downloaded a copy of the OS.
On the other hand, if you simply cannot wait to play with macOS Mojave, then know that at a minimum, you can continue to build and deploy with the latest beta software from our friends in Cupertino.
– Opinions are my own and not the views of my employer
Super quick post here. Sometimes when debugging your .NET Core application on Mac, you’ll find the port won’t free up, and thus you can’t redeploy without getting the following fatal error:
Unable to start Kestrel. System.IO.IOException: Failed to bind to address http://localhost:5000 on the IPv4 loopback interface: port already in use.
To fix this, you’ll need to fire up Terminal and enter the following:
â–¶ sudo lsof -i :5000
In my case, this outputted the following:
I know the error is referencing the IPv4 Type which allows me to quickly find the PID number, which I’ll use to kill the connection. I do this with the following command
â–¶ kill -9 18057
With that done, I can now get back to debugging my .NET Core web API on macOS.
We’ve all seen tutorials which demonstrate how to deploy a simple todo list backend to Azure but how many have you read that go onto secure it? In this post, I’m going to cover how I’m securing the Bait News v2 backend infrastructure as well as covering how to configure custom domains.
Why bother?
Apple announced in 2015 that Apps and their corresponding backend servers would need to support App Transport Security (ATS).
ATS was introduced with iOS 9 as a security enhancement to ensure all connections by apps use HTTPs. Initially slated to go into effect for all new app store submissions from January 2017, it has since been postponed with no update on when it’ll be coming into effect. Although the requirement has been delayed, it’s still something that all app developers should be implementing as it provides our users with added security, making man in the middle attacks impossible to go unnoticed.
Historically, you’ll see most developers (including myself), opt to turn ATS off to make our lives easier. Some will take a lighter touch and only disable ATS for a single domain (they’re backend) which is not much more secure than turning ATS off altogether. Either approach opens up your users and data to attack and should be avoided.
So what do we need to do to secure our app? Lets first register a domain for our backend.
Custom Domains
DNS
I’ve been using 123-Reg as my domain registrar for 10 years and continue to use them as I migrate my websites to Azure. Most domain registrars will also provide some basic DNS functionality but you would normally want to use a 3rd party DNS Service for more advance situations. In my case, I’m using 123-Regs DNS service and have added a number of CNAMEs pointing to Azure.
Adding records
Below you see the minimum required records needed to enable my custom domain.
Permanent Records
Temporary Records
To get started, I have added an A record pointing to the App Service instance using its IP address. You can find your App Service IP address by going into it’s Custom Domain blade within the Azure portal.
Once you’ve added the A record, you can then create the CNAME which will map www requests to your backends url. You can find your destination in the Overview blade of the App Service.
Verify Domain Ownership
Azure needs to know I own the domain I’m trying to map. To prove this, I’ll add two records to my DNS settings which are the temporary records listed above.
Once I’ve added the verify CNAME records, I can save and sit tight. DNS Records need to propagate across the globe, which can take up to 24 hours.
This is end result of what my DNS setting configuration looked like. I also created some CNAMEs to redirect traffic from subdomains to other Azure services.
Portal Configuration
To finish off, I need to configure the App Service Custom Domain settings.
Hit the ‘Add Hostname’ button and enter the custom domain.
After hitting Validate, Azure will check the DNS records to confirm the domain exists and that you own it. You should see something like this.
Hitting ‘Add hostname’ will complete the process of configuring a custom domain for your App Service. If you’re deploying a mobile backend, you may want to create CNAME record which maps api.domain.net to your mobile backend and whilst keeping www.domain.net mapped to a ASP.NET website.
Adding Security
SSL Certificates
As mentioned at the start of this post, enabling HTTPS prevents MITM attacks and ensures your communication between server and client is secure. Its pretty straight forward to enable within App Services but much like DNS, it can take a while (but this time its human factors rather than waiting for computers to sync up).
First things first, You’ll need to purchase a certificate. Â I opted to 123-Reg as they provide a few options to meet most users requirements and its integration with my domain management make it a no brainer to use.
I should admit that I did make a mistake when I first purchase a certificate, which caused a few days of delays, so its important to double check the type of certificate you’re purchasing. I had purchased a certificate which was for only www.baitnews.io. This mean that my mobile api of api.baitnews.io couldn’t use the certificate. 123-Reg refunded the first certificate and I tried again, but this time making sure to purchase a certificate which support unlimited subdomains. You can see below the original certificate has been revoked and the new certificate supports wildcards.
When you apply for a certificate, you’ll be provided a download which includes your certificate request (CSR) in a PEM format. You also get the private key which you’ll use later to create a new certificate.
Once you’ve been issued the certificate, you’re ready to create a new certificate which you’ll use in Azure for everything. This is a pretty easy process as we can use OpenSSL on almost any platform. I’m on a Mac but this works the same on both Windows and Linux.
[Output file name] -| What do you want to call the certificate?
[private-key.key path] The location of the private key. This would have been provided when requesting the certificate.
[wildcard.cert path] The location of the freshly issued certificate.
Once you press enter, you’ll need to type in a couple of passwords and then you’ll be set. It’ll look something like this:
You now have your certificate ready for uploading to Azure. The conversion of certificates isn’t the easiest of procedures to wrap your head around on the first few goes. If you’re worried about this step then keep in mind you can purchase SSL certificates through the Azure Portal, which skips many of the above steps! It does however add a small premium to the cost involved in securing your backend as you’ll find the certificate a little more expensive but your also required to store it in KeyVault.
Binding Domains with Certificates
Lets upload our new certificate to our App Service. To do this, head over to SSL Certificate blade and hit ‘Upload Certificate’. You’ll need to provide the password used to create the certificate.
If successful, you’ll see your certificate as been imported and is ready to use with your custom domains.
Add Binding
The last step is to bind out SSL certificate with our custom domain. Clicking ‘Add Binding’ will allow you to select both the custom domain and SSL from a drop down.
Hitting Add Binding will finish the process. You now have a custom domain mapped your App Service instance that supports HTTPS. Any users visiting your backend will be greeted  with the familiar green padlock in the address bar.
Wrapping Up
Adding custom domains and enabling secure connectivity between your mobile app and backend is extremely simple and theres no good reason not to enable it (unless you’re hacking on a demo or POC).
In the next post I’m going to cover how to expand our setup to to route traffic to the nearest App Service instance.
