Tuesday, November 24, 2015

Continual Delivery of an AngularJS ASP.NET MVC Web API Entity Framework SQL App to Amazon AWS using Visual Studio Team Services

I know, that title is a mouthful. But that’s exactly what it is! A team at my company, iVision, has been working on an app using the AWESM stack for almost a year now. The app is structured like this:

  • A SQL Database, tracked in source control as a database project
  • A repository layer based on Entity Framework
  • A REST-based web services layer built as an ASP.NET Web API project
  • A shared security library that allows sign-on from various sources and uses JWT to transport authentication and authorization information then rebuild the custom IPrincipal and IIdentity using a DelegatingHandler
  • An ASP.NET MVC application to host templates (we used this so we can restrict access to templates based on security using the built-in Authorize attribute functionality)
  • A single page Angular app built with TypeScript that is now hundreds of components and pages
  • NUnit unit and integration tests, with Jasmine tests for the client

The app is a total rewrite of an existing system that uses an object-oriented database. The environment is designed to continually synchronize data from the object-oriented database to the SQL database for testing and validation purposes. This gives us “continuous migration” so there are no surprises at go-live – all operations can be verified real-time against the legacy system.

The backlog contains hundreds of items for us to migrate over. Fortunately, the free software we use to manage it gives us “at a glance” visibility into where we are at. For example, this chart of story points by state makes it immediately clear we’re just under halfway through the backlog:


You may or may not know that Visual Studio Team Services (VSTS) features a full cross-platform web-based build system that supports DevOps start to finish. We’ve been using this system to track requirements (backlog), plan sprint iterations, map team capacity, conduct daily scrums, track burn down and provide real-time transparency to the customer of our projected release date based on average velocity over time. It also serves as our source code repository, continuous integration server, and finally continual delivery.

It’s always exciting to see a good plan come together when the sprint burndown looks like this:


The customer already had an existing setup with Amazon AWS, so we are not delivering to Azure. Not a problem! The VSTS system made perfect sense given the team size is four developers and it comes with five free licenses. The new build system provides a simple link to download and install an agent on the target machine. The agent enables me to authenticate with VSTS and configure attributes about the environment to enable automated builds right from the AWS environment. As long as the machine has a path to the Internet, there are no crazy firewall rules to tweak.

Once the agent is installed (in this case as a windows service) I never have to log onto the box again – everything is managed through the web-based build interface.

At a 5,000’ level the build steps I chose are captured here:


By default the build process will synchronize the source code on the build machine with the main repository. I chose not to clean it each time which avoids pulling down the full source tree. Despite the fact the app represents hundreds of thousands of lines of SQL, TypeScript, and C# code, the entire build process takes only a few minutes.

The first step is to build the solution. This will catch any errors early on and set up the environment to make the subsequent steps run more easily. At this stage the app is built but nothing has been deployed.

The next step is a PowerShell script I wrote to backup the existing database. The configuration in VSTS is simple: I just enter the path to the script. The script itself loads some dependencies, checks to see if an existing backup exists and deletes it, then performs the backup itself.


The next step is a Visual Studio build step, but instead of pointing to the solution, it points to the SQL project. The Publish target followed by a path to a publish file triggers the database upgrade. It uses the publish profile to connect to the local database, compare against the source version, then update any changes. If there are any issues the database was just backed up so we can easily restore after testing the upgrade.


The next step is to backup the internal website in case the deployment has an issue (so it is easy and fast to rollback). For this I use the “Copy and Publish Build Artifacts” block.


Finally, I can deploy the ASP.NET MVC Angular application. Because there are multiple web applications in the solution, I deploy at the project level using the “msbuild” block. The deployment will automatically apply my web.config transforms so that the correct database, services URL, etc. are configured. Notice that I pass the property to deploy on build and give it a publishing profile that I previously set up and checked into source control. I don’t need to restore NuGet packages because that was taken care of with the initial solution-wide build.


The same steps (backup, build) are repeated for the Web API project. That’s it! After the last step, the database has been upgraded, the web and service sites updated with proper configurations, and the site is ready to access. All of this can be done with the push of a single button (or run on a regular schedule) and if any issues are encountered, the backup images can be used to restore to a previously known state.

It’s so easy, I had to double-check the deployed apps the first time I did it because it built so fast and ran successfully. This is just sharing some of the process; the full cycle will include unit and integration tests as well as a “smoke screen” that can be run at the end to verify the build succeeded by accessing the running application.

Because the entire process is managed by VSTS, we have full clarity of the process from the product backlog item to the build itself, with changesets automatically linking requirements to code changes and the builds they were deployed in. If the build fails, it automatically generates a defect so the team can look into the issue and resolve it immediately. Overall this streamlines the development lifecycle and puts high quality software into the hands of our customer more frequently.

Happy DevOps!

Tuesday, October 27, 2015

Introducing the AngularJS AWESM Stack

I recently presented the AngularJS AWESM stack at the Atlanta Code Camp. This is a stack I’ve been using successfully for nearly four years now. It includes the following components:

  • A is for AngularJS
  • W is for ASP.NET Web API
  • E is for Entity Framework
  • S is for SQL Server
  • M is for ASP.NET MVC

Each component of the stack is a piece of a larger puzzle that makes it easier to develop quality code faster for single page applications and line of business websites.


The abstract for this talk: “Single Page applications have taken the business world by storm and drive many responsive line of business web experiences. Fortunately Microsoft has done a great job of keeping pace and provides the backend elements needed to build a full stack solution for the enterprise. In this talk, Jeremy Likness demonstrates how AngularJS, Web API, Entity Framework, SQL Server and MVC (ASP.NET) work together to provide a comprehensive platform to build secure, scalable enterprise single page applications.”

To learn more about how I leverage the stack and why it is beneficial, take a look at the deck:

You can also access the sample code and PowerPoint presentation on GitHub: The AngularJS AWESM Stack.

Sunday, October 25, 2015

The Top 10 Lessons Learned from Enterprise JavaScript Development

A week ago I presented a talk at Atlanta’s ConnectJS conference. The title of the talk was “The Top 10 Lessons Learned in Enterprise JavaScript.” Because it was a JavaScript-focused talk I decided to author the presentation in JavaScript using one of Google’s Html5 projects.


You can view The Top 10 Lessons from Enterprise JavaScript Development and also browse the source. The deck features frames that load live content to make certain points, so it may take some time to initialize in your browser and may flash some warnings. I took snapshots of the slides with dependencies in case you have trouble loading it.

In the purest sense, Enterprise JavaScript is simply JavaScript used in applications that serve the enterprise, typically via line of business applications. It is typical for these projects to be larger than direct-to-consumer or “brochure site” code bases. Some projects span years and involve hundreds of thousands of lines of code. Another important aspect that differentiates this class of application is the size of the team. I’ve worked on teams with 25 developers simultaneously working in the same code base, and even larger teams exist.

To summarize the deck, after working with JavaScript in the enterprise for nearly two decades I’ve learned these lessons:

  1. Yes We Can! – although JavaScript began as a scripting language to glue Java applets to the DOM, we can absolutely build complex mission critical line of business apps now that the language and supporting frameworks have evolved.
  2. Dynamic Requires Strict Measures – when you are working with large teams the dynamic nature of the language can quickly turn the code into a nightmare. It makes a lot of sense to use languages like CoffeeScript or TypeScript to add form and structure when dealing with larger teams or code bases.
  3. Forget Java and C# – not really, they will still have a place, but with the advent of technologies like NodeJS you can truly write your full stack with one language.
  4. DOM stands for “Demonic Object Matrix” – I’ve found that a lot of the blame JavaScript receives isn’t because of the language itself, but the inconsistent implementation of the Document Object Model across browsers. That is why it is more important than ever to leverage libraries like jQuery and Bootstrap to “normalize” access to the DOM, styles, and behaviors.
  5. Live on the Edge – yes, there was a funeral for IE6. But then things got worse. In this day and age I fight as hard as I can to get out of the rut of writing backwards compatible software for older versioned browsers. Instead, I ask that companies live on the edge versions.
  6. TypeScript is like Coffee – no, not like CoffeeScript. I’ve witnessed the before and after or a team working in pure JavaScript and then migrating to TypeScript and it’s like hitting the nitro button in a race car. Even JavaScript purists on teams I’ve lead have told me after using it they really see the value and are glad we made the switch.
  7. Frameworks Save Lives – I’ve witnessed more than a few heated discussions in forums about sticking with pure JavaScript and avoiding frameworks like the plague. Typically it is the high and mighty architect pontificating about how they mastered the language and everyone should either become an expert or not write code. That’s great for forums and maybe to catch the eye of recruiters but in the real world time is money and frameworks help us scale and deliver applications more quickly. I can ramp an Angular developer onto an Angular project far more quickly than I could on a project that features “Jeremy’s super ultra perfect because he knows JavaScript proprietary framework.”
  8. Don’t Just Write It. Build It! – this simply means we no longer have to use NotePad to author JavaScript. It is integrated well into IDEs but more importantly we now have excellent frameworks like Gulp and Grunt to help build JavaScript and web-based applications. Use them! ASP.NET MVC 5 embraces this approach out of the box. Microsoft’s Visual Studio Online build process now features specific build steps for installing Node packages and using package manages like Bower to pull down dependencies, then build apps using Grunt or Gulp.
  9. Be Testy. Be Very Testy. – the day and age when JavaScript testing was difficult is long gone. There is no excuse not to test your JavaScript code and do it in an automated fashion that gates check-ins and runs in continuous integration and continual delivery processes. If you’re not testing, you’re not serious about your app.
  10. XML is Dead. Long live JSON! – do I really have to qualify this one? Let’s finally put to rest that chapter of SOAP and XSLT that we all participated in and were glad to move on from. JSON practically writes itself.

I’m done. There is a lot more detail in the deck so please view The Top 10 Lessons from Enterprise JavaScript Development and also browse the source.