Uncategorized

Walkthrough notes in creating deployments and the Azure Deploy Project

Recently I’ve been asked to do some complete demos of building out complete release pipelines similar to what Donovan and company have been doing for at least a year now. My craptop has been bottoming out lately and I’ve sworn to “walk the walk” when it comes to making the leap from Visual Studio local on my box to editing/pushing out code using Visual Studio Team Services (VSTS). As VSTS has changed quite a bit since I last looked at this, I thought I’d write up my walkthrough notes so you can do it yourself. Trust me – setting up CI/CD is now LAUGHABLY easy. There’s really no excuse not to try it with your new application.

If you want more information on ARM templates, setting up release definitions, build agents etc – check out the “Zero to DevOps” epic presentation by Donovan Brown showing what was behind the scenes. Note the first comment is about adding SSDT/SSIS as part of the buildout as a suggested feature, I would love this!

In Brief

  • First lets set up some code to import.
  • Create four websites in the Azure portal you want to point to. Let’s create a D, Q, and P set of sites.
  • Now let’s set up a build.
    • Set up build – ASP.NET. Call it “XXX_CI”, select repository
    • Click on the Trigger tab, and select “Enable CI”
    • Click “Save and Queue”
  • Associate this build with a release:
    • Release tab – create a new release definition. When it asks you for the target environment name, give it a name – “Dev” – Azure App Service Deployment template, and select Apply.
    • Click on Artifacts – select your project, and the “XXX_CI” build definition.
    • Enable CI by clicking on the lightning bolt on the artifact, top right.
    • On the Artifacts object – select the “dev” environment. Select the dropdown on the subscription to pull in your Azure subscription. Here we are going to point ot “Phoenix360D”, our destination dev website.
    • Then we edit the index.cshtml file and add some nonsense verbiage. Pull it up in the site – and voila! Any changes we are making flow instantly through to dev where they can be tested.

See below for notes on setting up multiple deployments and creating a DevOps Project.

Full Walkthrough Notes

Note there’s not one original step in here, I just walked thru the steps in this doc like a good, obedient zombie.

Creating Your Environments

First go into the Azure portal     

  1. Log onto portal.azure.com
  2. Create three new websites by clicking New -> Web + Mobile -> Web App.

According to the notes here – https://docs.microsoft.com/en-us/azure/app-service/azure-web-sites-web-hosting-plans-in-depth-overview – you only need to create a new app service plan if a given app is resource intensive or you need to scale it independently. That’s not the case here – we can use one app service plan for all four environments (XXXAPPNAME + D, Q, P). In contrast, the idea behind resource groups are – you update them as a group. They share the same lifecycle, permissions, and policies – you can update security to this batch of resources as a group for example. So we’ll be creating one app service plan, four diff resource groups. We’ll create three websites – see below for “Phoenix360D” – with the appendix -D, Q, P – dev, QA, production.

Depending on current demands Azure should spin each of these up in a few minutes. Now we’re good to go, all 4 environments have been spun up and are running on Azure. And we have a build running successfully.

 

Getting Our Build Started – Single Path

Next, we need some code to work with. If you don’t have your own, no worries, we can give you a very nice working sample complete with test scripts.

  1. Log onto VSTS and click on your Code tab. Import using https://github.com/adventworks/aspnet4-sample – see the nice screenshot below:

  2. Once this is done – you should be on the Code tab – select the “Setup build”button on the right. Select “ASP.NET (PREVIEW)”, and select APPLY.

     

Side note, check out all the steps it stubs out for you below on the left. Whoa!

  1. Give the resulting template a good name– I chose Phoenix360_CI – and select your repository you just created. Here I’m using a Hosted 2017 build agent but you could also use your onprem TFS2017 build agent if you so desire.
  2. And, last, I select the repository we just imported:

  3. From here I can almost see the end of the tunnel – click on Triggers and enable the trigger for continuous integration. (Note you can also set scheduled builds at a particular time of day on this tab.)

  4. Click on Save & Queue, top right. Enter some notes on your commit, and on the popup window click Save & Queue again.

  1. If you’ve done this right – you’ll see the following in your build definition:

 

  1. Who, that build URL there is just begging to be clicked on. Let’s click on this:

  1. To test if this is working – go into Code again and make a hand edit to a web.config file, in the header. If we’ve done this right, we should be seeing a build kick off after our commit of this change:

Click on Build and Release tab. Sure enough, our code commit triggered a build:

  1. This is really quite nice – click on the latest build, and select the Test tab for example. It shows us the tests and the run length:

     

     

     

 

  1. Click on the Release tab and add a new release definition. There’s a few templates to choose from here but it’s definitely easy to start with a precreated template vs rolling your own. Let’s click on “Azure App Service Deployment” and select Apply.

  1. Don’t get overwhelmed – just click on the Add Artifact option. Enter in the following values – the Build Definition you created earlier. Note the different version options as well in the dropdown:

  1. On the Artifacts node you just created – left side – notice that little lightning bolt on the top right? That’s our continuous integration trigger. Let’s click on this and make sure CI is all set up:

     

    And then click again on that Artifacts node on the right, and set up your environment including the destination endpoint:

     

    Create a new release – as you see below – and save it to the default folder. We’re golden!

     

     

    Does it work? Let’s go into the code view and make a change. It should populate out to dev:

     

     

     

     

     

     

     

Setting Up Multiple Deployment Paths

Continuing with this wiki:

 

See below. Clone your dev item – and set it up so the pre-event trigger (lighting bolt, left side) is set to “After environment”. This is also where you can set up approvers and manual stage gates.

 

 

Clicking on the pre deployment conditions lets me set the deployment to trigger after the environment is ready or based on a release trigger (i.e. a simultaneous rollout to DEV/QA). You could also set your production rollouts to a less busy time of day for example.

Then I go into each task for the new cloned environments above and change the deployment pointer to QA (or Prod).

Let’s get fancy and change the deployment to prod to be manual.

Now when I create a release – look how nice this is:

 

And sure enough when it hits prod I get this nice little alert that I need to review the changes and approve a move to prod.

 

Sure enough, now any changes to my source control kicks off a full set of releases out to all 3 environments. Noice!!!!

 

 

 

 

 

DevOps Projects

Log in to VSTS.

Create a new DevOps Project. New (top left), Everything, and filter by “devops”. You should see the DevOps Project below appear.

Let’s select .NET below. But we could import our app or use a ASP.NET site based on PHP, NodeJs, Java, etc.

 

On the next screen choose either ASP.NET or ASP.NET Core. Select Web App in the next window – it’s the only option as yet. Lastly choose your existing MSDN subscription – assuming you have one – and a new project name.

 

I’ll next see a “Deployment in Progress” notice in the taskbar. Super cool!

… and at last I get this shininess.

 

There’s no magic going on here. You can browse to the Build definition and inspect what its doing – and then click on the Dev release and edit the properties. See? It’s exactly what we created before, manually.

Really I’m very glad that I took the time to do this manually first. It really gives me more of a comfort level when it comes to setting up release pipelines manually.

 

Dead ends and miscellany

An annoying issue was in the Artifacts, when I’m trying to point to the correct environment, it kept blowing up with “Couldn’t authorize to AAD. If popup blocker is enabled in the browser, disable it and retry again.” I tried changing adblocker in Chrome but that didn’t fix anything; same with Edge. But, classic IE got me a little further. This doc gave two options – https://docs.microsoft.com/en-us/vsts/build-release/actions/azure-rm-endpoint. I tried to log in but the “User May Add Integrated Applications” under the classic portal was already set to Yes. Tried again in Chrome, went to Release and tried adding a new Azure Resource Manager Service Endpoint. Turns out that wasn’t what it needed anyway.

I also had some subscription issues, where my default directory needed to be changed – that was really killing this walkthrough. Good news was – I submitted a ticket, Sev A, and got a call back from a very competent subscriptions helpdesk person in about two hours. Excellent. Really, I was quite impressed, it totally fixed a very longstanding issue.

 

Helpful sites to do this yourself

Advertisements

Experiments with tiling and FontAwesome, and image hotspots

Just a few notes to dash off today before I’m back to the grind.

Metro and FontAwesome

I wanted a Metro tile look without having the high overhead with the Telerik set of controls, and a Windows 8 or WPF application was off limits per my client. And, I only had a few days to put together a demo. What to do?

Well, the good news is there’s a host of CSS options for you out there. This site has a comprehensive set of stylings that work OOTB. The one I chose was metro-bootstrap from this site – http://talkslab.github.io/metro-bootstrap/ – and a full description of sample components a la Bootstrap are here: http://talkslab.github.io/metro-bootstrap/components.html. So putting together an icon was fairly easy. (On FontAwesome, here’s an icon cheatsheet – excellent! http://fontawesome.io/cheatsheet/) And in a jiffy, I had a clickable interface that displayed tiles without having to jump through a lot of hoops – so I could focus on the data and not the look and feel. Yay!

Hotspots

Feels weird to say this but I’ve never put hotspots on an image before. Yet the operators at this facility think in terms of physical machines – so it makes sense for the UI to key off of a factory layout. The idea is, when you hover over a particular area or click it, a list of the part numbers in progress at that station will display. To do this, I installed Expression Web and took my snapshot and dropped a set of rectangular hotspots on the image:

Once this was done I took the raw HTML and translated the coords to a set of Left/Top/Right/Bottom elements the way the asp:ImageMap control prefers, see below:

 

And, voila – a clickable image map. HTML5 goes even further with its <map> element – you can do some pretty neat things without having to resort to a ImageMap or a similar control, and keep it native. Enjoy!

Other Links

 

 

 

 

WebAPI Blitz

Had a good buddy ask me a few minutes ago about exposing data entities in WebAPI. It’s quick, and almost painless…

Start with creating a new project called WebServices or the like in Visual Studio 2013. Select the WebAPI profile – we’ll only need MVC/WebAPI pieces, not webforms, for this sample.

Start with an Entity Framework data model – here I used the Purchasing.Vendor table from AdventureWorks2012. If you don’t have EF, but it’s POCO, no biggie – you can still right-mouse click on any of the entities and generate views/controllers. Build the project – EF uses Reflection so we need to run a build to work with these entities and expose them in WebAPI.

 

Right mouse click on the Controllers folder and select Add, New Controller.

In the next screen select the Web API 2 Controllers option.

In the following screen, select your exposed table and make sure you generate a new Data Context as below. I always use the async controller actions by default.

Visual studio will think a little, and then you’ll see the auto-generated class. Look at all those scaffolded goodies!

Run a publish, and navigate using one of those handy REST api calls documented above. For example, sending <myserver>/api/Vendor returned this:

 

I’m going to attach the ZIP folder of the project. So easy, it feels like stealing!!! WebAPISample

 

For more detail, see the post here – https://driftboatdave.com/2014/01/13/webapi-the-new-wcf-data-services-and-knockoutjsmvvm-explorations/

 

 

 

Architectural patterns in Microsoft-land: Gathering requirements

Currently we’re examining different ways of coming out with a second version of our shopfloor software, and there’s a lot of pressure to start rolling out a UI – even ahead of a stable data layer, or wireframes of how the end users want to have it interact and display information to our user base.

UI code is expensive. Putting a few days into asking some basic questions about unspoken requirements is cheap. Otherwise, you’re faced with the age-old “you gave me what I asked for but not what I wanted” relationship-ender that’s the bane of so many IT projects.

Usually business and user requirements will be defined (to some extent) at the beginning of the process. Let’s talk about system requirements – both functional and non-functional.

Functional requirements (what the system must do – “the system shall notify the administrator when a package fails) include things like the following:

  • Business rules
  • Admin functions
  • Authentication, auditing, security
  • External interfaces
  • Reporting
  • Historical data
  • Regulatory requirements

Non-functional requirements (how the system should operate – “what’s an acceptable amount of uptime?”) include:

  • Scalability
  • Capacity
  • Availability
  • Reliability
  • Recoverability
  • Maintainability
  • Performance
  • Security
  • Regulatory
  • Manageability
  • Usability
  • Interoperability

Actual users will help you with the functional requirements; non-functional requirements will come from stakeholders. Once stakeholders are identified, you can gather requirements with a variety of methods (interviews, focus groups, questionnaires, observation (either direct or indirect), documentation, and researching similar projects.

Once this is done, you could split up your target audience into personas (including a name, photo, demographics, a descriptive paragraph, and needs/goals/features from a user perspective). Once this is done, you can refine your broad list of requirements into a very fine-tuned list of requirements – including a rationale, success criteria, and a level of importance. This key and often overlooked step will help you deliver a project that the users need, instead of just what they want.

For my project, I doubt I’m going to go as deep into the sensy-style personality demographics that some do – for an internal system we’re not customer-focused enough to care where someone falls on the liberal-conservative or trendy-status quo axis. But I will take the time to recognize that we have three user types – Operator, Engineer, Admin, and Executive – and split up broad requirements into a more focused matrix. This will give us an actionable list of to-do’s, so we won’t waste time writing UI code that doesn’t fill a specific need. Something like this…

 

As I refine this and get a survey going – our stakeholders are tied up 90% of the time in meetings, so an online survey on SharePoint or SurveyMonkey may be the go-to solution – I’ll create some new posts. I’m happy that we’re being a little more methodical in our second version of the software. Nothing’s worse than thrash when it comes to developer happiness and productivity!

 

Helpful links: