Showing posts with label Development. Show all posts
Showing posts with label Development. Show all posts

Wednesday, February 17, 2016

Application Insights and TypeScript

I’m actively involved in creating extensions on VSTS and one of the questions that comes up a lot is on Telemetry. Are people using the extensions, how are they using it and what about errors and exceptions? It has become such a topic of discussion that Will Smythe has actually gone ahead and given some guidance on how to add Application Insights (AppInsights) telemetry to your extension.

He gives a good overview and example of using AppInsights in a simple JavaScript (and in fact an html page) type application. Personally I prefer using TypeScript to do my JS development.

The method that Will explains and Typescript do not mix as seamlessly as I would like. Luckily there is hope.
Microsoft also provides a TypeScipt type definition for their AppInsights api. Currently it is in preview, but I have not had any problems with it.

You can install it via NPM ilke this:

Install-Package Microsoft.ApplicationInsights.TypeScript -Pre

Once it is installed, it will dump the libraries into the packages folder in the root of the project. There should be two libraries, the JavaScript and the Typescript types.
clip_image002

Under the JavaScript folder (Microsoft.ApplicationInsights.JavaScript.0.21.5-build00175 in this case) you will find the scripts in the content\scripts folder. It has two versions, the full and minified version of the library. In our instance simply copy the minified version (ai.0.21.5-build00175.min.js in this instance) to the scripts folder of your extension.

The package should already have added the typescript definition file to your scripts folder, but in case it has not, under the TypeScript folder (Microsoft.ApplicationInsights.TypeScript.0.21.5-build00175 in this case) you will also find content\scripts folder that contains the type definition (ai.0.21.5-build00175.d.ts in this instance). Copy that to your TypeScript definitions folder.

Now you should be ready to use them. Include the JavaScript library in your extension and reference it in your html page, and add a reference to the TypeScript type definition in your TypeScript files.

/// <reference path="ai.0.21.5-build00175.d.ts" />

To use the library, you need to configure it using a configuration snippet. The configuration snippet contains the instrumentation key that has been setup (following Will’s post):

var snippet: any = {
   config: {
      instrumentationKey: "<<your instrumentation key>>"
   }
};

You can pass this into the initialisation object :

var init = new Microsoft.ApplicationInsights.Initialization(snippet);

And then from the initialisation object you create an AppInsights instance:

var applicationInsights = init.loadAppInsights();

On the AppInsights instance you can go ahead and start to capture your telemetry using the following:

trackPageView(name?: string, url?: string, properties?: Object, measurements?: Object, duration?: number): void;
trackEvent(name: string, properties?: Object, measurements?: Object): void;
trackAjax(absoluteUrl: string, pathName: string, totalTime: number, success: boolean, resultCode: number): void;
trackException(exception: Error, handledAt?: string, properties?: Object, measurements?: Object): void;
trackMetric(name: string, average: number, sampleCount?: number, min?: number, max?: number, properties?: Object): void;
trackTrace(message: string, properties?: Object): void;

The full code would look something like this:

var snippet: any = {
   config: {
      instrumentationKey: "<<your instrumentation key>>"
   }
};

var init = new Microsoft.ApplicationInsights.Initialization(snippet);
var applicationInsights = init.loadAppInsights();
applicationInsight.trackPageView("Index");
applicationInsight.trackEvent("PageLoad");
applicationInsight.trackMetric("LoadTime", timeMeasurement);

Thursday, November 12, 2015

JDeveloper and TFS

Oracle developers should be well versed with JDeveloper.
On the SQL side of things, Oracle actually has a plugin available for Visual Studio "Oracle Developer Tools for Visual Studio" giving you a very similar experience to the SQL Server Data Tools.
JDeveloper on the other has is "a freeware IDE supplied by Oracle Corporation. It offers features for development in Java, XML, SQL and PL/SQL, HTML, JavaScript, BPEL and PHP".

This should not stop you from using it with TFS though…
The only thing that intrigues me is the use of workspaces to establish the connection as apposed to creating a connection directly to TFS.

Enable the plugin:

  1. 1) In JDeveloper, go to the extension management page by selecting Help->Check for Updatesclip_image002
  2. Click Next on the sources viewclip_image004
  3. Wait for the extension to load and then type in “Team System” in the search box. This should highlight the Team System extension.
    Select it and click next.clip_image006
  4. Wait for it to download and install, you will probably have to restart JDeveloper.clip_image008
  5. Create a workspace either using Visual Studio or via command line :
    https://msdn.microsoft.com/en-us/library/ms181383%28v=vs.120%29.aspx
  6. Connect to Team System ( Team->Connect to Team System). It may seem that nothing has happened, but go to the next step…clip_image010
  7. Select the workspace created in step 5 (Team -> Team System->Set Workspace and then select the workspace from the list presented):clip_image011
  8. When you open your applications, you should be able to add, check out etc. you files from TFS: by right clicking any files and selecting “Versioning”clip_image012
  9. You can preview the pending changes from Pending Changes (Team-Team System -> Pending Changes) pane.

TFS is no longer "just" a Microsoft / .Net tool… To prove it, have a look at http://java.visualstudio.com.

Thursday, April 9, 2015

Agile : Failing is a good thing!

I've had this discussion a couple of times over the last number of years, and people tend to not believe me when I say that in the Agile world, we want to fail!
For emphasis I will repeat that : In the Agile world we want to fail

Let that sink in a bit…

OK, now that you think I am full of it and must not have a clue as to what I'm speaking about, lets continue.

Waterfall or Structured methodologies / processes
Let's take the example of a waterfall approach. We analyse the work, get to development and finally deliver the functionality. The only problem is that this could take anywhere from months to years to get the first working software out there.. And now the customer or client can look at it and decide that this is not what they wanted in the first place or the business has changed making it irrelevant.

Here are some very interesting numbers on failing software...
The Standish group released some stats last year stating that "Only 9% of projects in large companies were successful." and that "The most projects, 37.1%, were impaired and subsequently cancelled (Resolution Type 3) in medium companies, compared to 29.5% in large companies and 21.6% in small companies."

With this high rate of failure, how can it possibly be good? Well it is not! Failure is never good, but it is inevitable. What we do however strive for is to mitigate the losses that are incurred due to the failure.
How do we do this?

Fail fast fail often…

Agile methodologies / processes
In contrast to the structured "long running" processed described above, in agile we get working software into the hands of customers, business or clients as soon as possible. They can then interrogate it and communicate where the problems (if any) are and what needs to be done differently or how to fix it. We can then"pivot" to fix the issues, change the focus or scrap unnecessary functionality to continue delivering business value.
The difference here is that if we do "fail", we lose an iteration's worth of work, which should be 2 - 3 weeks. Compare this to the months or years that a structured process could take...

Another difference is that we can then learn from the mistake, make an adjustment and continue delivering value. In structured processes the monolith has been developed and you may very well be too far down the path to make the required changes or fix the issues.

In a nutshell:

Failure is not good, but it is inevitable. Things are changing too rapidly for us to start with a plan and be able to deliver relevant software months/years later.

We need to deliver small chunks of work that can be interrogated and evaluated, gather that feedback and communication and adjust what and how we do things to mitigate the risk and exposure of the failures or losses!

Friday, October 10, 2014

Move from GIT to TFS Version Control

I have dealt with a couple of clients recently who were very keen to get into the GIT repo's that are available in TFS 2013. The unfortunate truth is that GIT is not the "same" as the widely used TFS Version Control (TFSVC), SVN, VSS source control systems. Some teams tend to have a problem with this and, after numerous missing changes/files and problems with branching, commit vs pushing and merging issues, will inevitably ask : "How do we go back to what we know?".

There are tools to move from VSS & SVN to TFSVC and there are instructions to move from TFVC to GIT, but what about GIT to TFSVC? Well luckily, for a simple migration, you do not need any commercial or "3rd party" tools.

You do need to get your hand on GIT-TF and optionally the git client, and you are "a" for away.

1) Clone the repository

git clone http://<<servername>>:8080/tfs/<<Project collection>>/<<team project>>/_git/<<repo name>>

2) Replace the repository bindings

git remote rm origin
git tfs configure http://<<servername>>:8080/tfs/<<Project collection>>     $/<<team project>>/<<destination folder path>>

3) Finally check in the changes

git tfs checking --deep

Remember the --deep parameter - this will replay the commits as check-ins in TFS


The only thing you should be aware of here is that the check-ins will happen in chronological order, but the time will reflect the time and date that the check-in is occurring and not when they were committed into the GIT repo.


Wednesday, July 30, 2014

TFS 2013 Pre Build Script Assembly Version Updates

I was looking at a "simple" way to update the TFS build definitions and adjust the Assembly versions of the projects being compiled. I came across this article (http://msdn.microsoft.com/en-us/library/dn376353.aspx) leveraging the pre and post build scripts that are available in the newer build definitions.

The problem I had with the scripts included in the TFS Build Extensions is that it uses the Build Number or Label. This does not really make sense to me so I started hacking at it.
Fortunately it was not as big a task as trying to delve into the new build definition's workflow and trying to find the variables that "used to" exists.

If you are interested, I have posted the resulting PowerShell.
Simply add this to the TFS repository, and then reference it as a pre-build step in your build definition and you will notice that your AssemblyVersionInfo.cs files are updated before the build, replacing the revision to the changeset number.
This will give you a reference from the actual assemblies back to the code or changeset that they originate from.



Enjoy!

Monday, February 10, 2014

TFS Build "Machine"

The TFS Build environment can be a bit complex with a couple of things playing on each other. Let's see how everything fits together.

TFS Build

Let's start with the basic build… When you install TFS, and you "Configure Build" using the TFS Admin console, you are in fact setting up 3 components. The build service, controller and as many agents as you may need.

The build service is a communication mechanism between TFS and the build components. You need to have a service running on every build machine, whether or not that machine only has agents or contains a build controller and agents. The controller (as its name implies) controls the agents and manages which builds are being handed off to which agents. Finally, the agents preform the work.

image

The controller and or the agents can run on separate machines. So you could have an instance where TFS in on Serv1, the controller and potentially one agent is on Serv2 and another 2 agents are on Serv3. One thing to note is that a TFS Project Collection can have multiple controllers associated to it, but a controller can only service one project collection.  You can also only have one controller installed on a machine.

You may also be tempted to have multiple controllers to a team project collection, but in most cases you should only require one controller and then a number of agents spread across multiple machines.

Lab Management

Lab Management brings with it a bunch of additional resources and components. More specifically it has its own Test Controller and Test Agents.
You would use test controllers and agents when you want to "run tests remotely, distribute tests across multiple machines or run load tests".

image

Unlike the test agents in the previous section, you would only have a single test agent deployed on a machine. These components form part of the BDT (Build, Deploy and Test) workflow.

Release Management

The new kid on the block, Release Management, leverages the default build to obtain compiled artefacts. In fact it has a custom build template that actually instantiates a release pipeline in Release Management.

Recap

So to recap, TFS has the primary build (Team Build) infrastructure that consist of a build controller and build agents. This is used to compile and do initial tests on the code that is in version control. Then Lab Management with its test controllers and test agents takes this a step further and allows some deployment workflows and once again adds test capabilities.

Tuesday, August 6, 2013

Software Deployment (Part 2)

In the previous post I was discussing how one could go about packaging software to make the long journey from development into production.

image_thumb2

In this post I will take a brief look at a couple of tools or applications that I have come across, to take those packages and automate their deployment. Using them will lower the friction and reduce the reliance on human (and possibly problematic) intervention.

 

Continuous Integration

Once again, we all know that continuous integration is a “basic right” when it comes to development environments, but it does not need to be limited to development environments. If you are using one of the numerous CI environments, extending it to deploy the packages in the previous post should be fairly simple.

I have done this a couple of times to varying degrees of complexity in TFS. It is possible to alter the Build Template to do pretty much anything you require. Setting up default deployment mechanisms and then by simply changing a few parameters, you can point it to different environments.

I have done everything from database deployments, remote msi installations to SharePoint deployments using just the TFS Build to do all the work.

 

3rd Party Deployment Agents

InRelease

You must have heard by now, a very exiting acquisition from Microsoft was the InRelease application from inCycle. This basically extends TFS Build and adds a deployment workflow.  It takes the build output (which could be anything that was discussed in the previous post) and, once again, kicks off a WorkFlow that includes everything from environment configuration to authorisation of deployment steps.

In SAP they speak of “Transports” between environments, and this, in my mind, speaks to the same idea of transporting the package into different environment.

I’m really excited about this, and I can already see a couple of my clients making extensive use of it.

image

Octopus Deploy

Another deployment focussed package that I have been following is Octopus Deploy (OD). OD works on the same premise as InRelease, having agents/deployers/tentacles in the deployment environment that “does the actual work”.

A key differentiator is that OD sources updates etc. from NuGet feeds, so you need to package your deliverables and then post them to a NuGet server. As I explained in the previous post, NuGet is a very capable platform, and with a number of free NuGet servers around, you can very easily create your “private” environment for package deployment.

System Center

Do not forget System Center, or more specifically System Center Configuration Manager (SCCM). SCCM is a great way to push or deploy applications (generally MSI’s) to different servers or environments. Very capable in its own right, and more importantly (assuming you have packaged the software properly) can be setup, configured and managed by the ops team.

Thursday, July 18, 2013

Software Deployment (Part 1)

So, one of the tenants of ALM is automation, and probably one of the most time consuming and problem prone aspects of the lifecycle is deployment.

It just so happens that I have been in a couple of discussions around how the gap between when the developer “completes” and what is moved into QA, UAT or Prod environments is actually bridged. In fact, I know of a notable company losing a great deal of money due to a critical system being down for a day because one step was not completed by the deployment team.

image

We all know that continuous integration is a “basic right” when it comes to development environments, and recently there is an emphasis on continuous deployment, but how do we package and move deliverables from one area to another?

So I want to start with packaging.

There are a couple of ways that we can package our applications, based on the technology that they are built in, the target environments and/or the amount of configuration that is needed when deploying.

Remembering that “If You're Using XCopy, You're Doing It Wrong”, these are a couple of techniques / tools I would keep in mind:

Installers (aka MSI)

Visual Studio used to have a “Microsoft” installer project type that was available with VS 2010 and earlier. It was fairly intuitive, and I know a couple of companies that have not considered upgrading due to an investment in this project type.

InstallShield Limited Edition was also packaged in VS 2010 and is still available with VS 2012, although limited, it does provide basic functionality and some integration with build environments.

There are a couple of other msi creations, but my favourite has to be WiX. It was actually almost a part of Visual Studio, but then it was decided that that would limit the release cadence and inhibit the flexibility of fixing changes and adding new functionality.
It is a highly flexible platform, plugging into builds without much effort.
And if you are wondering if it is any good, a large number of Microsoft’s applications are actually released using a WiX based installations.

MS Deploy / Publish

You have had the ability to “publish” sites in Visual Studio for a while now, but it was basically a “smart” xcopy. In recent years there has been quite a bit of work done on the Web Deploy or MS Deploy utilities. It is basically an extensible framework with providers that provide certain capabilities.
One of the more significant abilities is to deploy web site “packages” to IIS, then there is the “dbDacFx” provider that will actually deploy database changes to target servers as part of the deployment.
This is indeed a powerful tool for the deployment arsenal, especially when working in load balanced and “highly available” environments.

Integrating this into your build is also a synch, merely add a couple of msbuild parameters and you are a-for-away. More complex publish scenarios may involve you resorting to the “InvokeProcess” activity, but that is not so bad either.

(Indeed, Scott Hanselman’s quote "If You're Using XCopy, You're Doing It Wrong” is a session on web deploy that he did)

ClickOnce

If you are working in “client deployable” environments, such as Winforms, or Wpf applications, ClickOnce should definitely be a consideration. It is once again easy to integrate in a build process and if you can get away with merely “copying” assemblies across, then you have a winner.

NuGet

NuGet is fast becoming the de-facto standard for packaging components in the development environment. Companies have also started adopting it in their release management due to the ease of integration and modification. It is a very simple, yet powerful way of packaging and publishing components. With configuration, and even source code transformations and PowerShell scripts, you can pretty much do anything during install or remove actions.

Quick Comparison

  MSI MS Deploy ClickOnce NuGet
Database Deployment bullet_tick bullet_tick bullet_cross bullet_tick
Install Time UI bullet_tick bullet_cross bullet_cross

(single prompt)

bullet_cross
Web Sites bullet_tick bullet_tick bullet_cross bullet_tick
Windows Application bullet_tick bullet_tick bullet_tick bullet_tick
Extensible bullet_tick bullet_tick bullet_cross bullet_tick
Build Integration bullet_tick bullet_tick bullet_tick bullet_tick
Automatic Updates bullet_tick bullet_cross bullet_tick bullet_cross
GAC Installable bullet_tick bullet_tick bullet_cross bullet_tick