This article constitutes Part 2 of a series of articles covering our CA’s Agile Vendor Pool RFI response process. In the previous article, we focused on our user-centric approach and how we responded to the first seven plays from the Digital Services Playbook. In this article, we will dive deeper into our team’s open-source tool stack.
Our development team formed quickly to meet CA’s Vendor Agile Pool RFI requirements – and build a notification service based on open-source tools. We used an Agile approach, and we designed the solution to scale and distribute using modern open-sourced DevOps tools and techniques. We had about three weeks.
Given the necessity to default to modern open-source software for the solution, our technical team began brainstorming on the right product stack during our “Architecture Sprint.” In this initial sprint, we bolted together the following open-source product mix:
- .NET Core
- JWT for authentication
- xUnit for unit testing
These open-sourced products represent all architectural layers necessary to complete the application (frontend, backend, etc.). In addition to meeting the goal of using open-source tools to develop our prototype, our team also integrated the open-source tool from tree.tiaga.io for our project management needs. This allowed us to document and share the sprints, user stories, and tasks with the entire team.
At the center of our development tool choice was Microsoft’s .NET Core. This open-source tool is a modular and high performance implementation of .NET for creating web applications and services that can run on Windows, Linux and Mac platforms. Our team’s expertise with C# and the productivity afforded by the Visual Studio Community made this an ideal choice for our REST API needs.
This screenshot shows the build-time test functionality available in Visual Studio. Using XUnit and Visual Studio test projects, developers can quickly markup test methods for Visual Studio to automatically run at build time eliminating any extra steps for testing. Deployment can also be connected to the results of the tests only allowing deployment to complete if all test cases pass. Details for the results of the test cases are also easily accessible to developers helping them resolve build and test errors.
We elected to use xUnit as our open-source library for testing C# code so that our testing suite could be built directly into Visual Studio. This was an important consideration; it increased our reliability when testing the service layer. Our team had a great experience with xUnit and Visual Studio. We had continuous integration and automation testing during this short project. This area of the development world has grown by leaps and bounds in recent years. Being able to build software and simultaneously run all test cases ensures code quality at tremendous speed. This increases developer productivity, reduces bug fix cycle times and immensely raises the quality of software.
Perhaps the most established open-source tool that our team used was MySQL. It is hard to refute their website’s claim to be the “world’s most popular open-source database,” its popularity is a testament to its usability. Our team was able to rapidly build a robust Azure-based MySQL environment to serve as the backbone of our data-driven prototype.
Selecting MySQL also allowed us to leverage the MySQL Connector for .NET Core, another excellent open-source library that connects .NET Core to MySQL using an ADO.NET-style implementation. Our team knew we could implement these tools for an efficient, and easily maintainable, data layer. The team ultimately opted to avoid an Object Relational Mapper (ORM) because of the need to efficiently handle large data sets – in this case, of alerts and emergency data.
Token-based authentication has become the de facto standard in web development to deliver stateless and session-less applications with REST APIs and other services. For us, using tokens meant that our application could easily be evolved into native or hybrid mobile apps and even authenticate with other APIs that could consume our data. This meant greater ease of use and expansion of features for our users and IT teams alike. We chose to adhere to the IETF 7519 standard of JSON Web Token, or JWT, for our token system. JWT is a compact, URL-safe, means of transferring claims between parties. JWT is widely considered the ideal token authentication design.
After selecting .NET Core and MySQL to power our service and data layers, and JWT to secure access, the architects focused on selecting UI components. Modern web development has shifted to make Single Page Applications and toolsets easily available. It is easier than ever to generate beautiful, loosely-coupled, highly-testable websites quickly and efficiently.
Ultimately, the team selected Angular as the frontend framework. We were able to create modular and highly reusable components quickly. Angular is also easily extended with Bootstrap, an excellent responsive theme framework that we selected to make the prototype available on virtually any type and size device. The native touch friendliness and responsive formatting that Bootstrap is famous for made it the best choice for our application.
With a mandate of deploying to any scalable hosting environment, our team turned to Docker to containerize the application. This approach allowed us to build a scalable container with only the necessary software decoupled from the operating system. With the installed Docker toolset, our team was able to leverage the containers to quickly scale and deploy to any environment. This key take-away is that this directly eased our testing and development workload.
The final decision our team needed to determine was which production environment to use. The team selected Azure. There were several critical factors that lead us to choose Azure, including:
- our team’s familiarity with the platform & tools,
- the availability of a mature DevOps toolset to allow continuous deployment, continuous monitoring, and log file management, and
- its service-based environment allowed us to automatically scale the system to meet demand.
An overriding theme to the open-source initiative is to develop software by and for the user community. To this end, our team used Swagger to document our RESTful APIs. This framework allowed us to describe our API with a common vocabulary in a way that would allow other developers to use our messaging and data services.
This prototype proved that an experienced development team could quickly come together to meet a hack-a-thon type development challenge and build a notification service based on open-source tools, with an Agile approach that could scale and be distributed using modern open-sourced DevOps tools and techniques.