DevOps Digest 201: Considerations for Building a Modern Web Application Using Version Control
In this issue, we’ll consider what it takes to create a fully functioning continuous integration (CI) system, before building a sample project that’s simple, but still designed with the complexity of today’s development burdens in mind. Don’t worry if you’re not a DevOps wizard, it will be easier than you think!
With an eye toward honoring the origins of the DevOps movement, we’ll choose a web application for our sample project.
The days when web applications consisted of some text and a few common gateway interface (CGI) calls are long gone. Quite the contrary, it’s not uncommon today for development goals to include:
- Providing a cutting-edge, in-browser experience
- Focusing on mobile responsive sites with a path to a native/hybrid app
- Offering important data and/or integrations through web endpoints
- Emphasizing database/storage-vendor neutrality
- Displaying in multiple languages
- Supporting multiple deployment modalities
- Reaching the target market immediately
Our sample application doesn’t need to do all of those things, but it does need to feature an architecture and design that makes it possible to do each of those things.
In order to build out a responsive mobile design and offer at least a path for a native/hybrid app, we’ll need to leverage a web application layout framework like Bootstrap or Foundation. Consequently, we have to consider languages and platforms that are capable of sharing code with the languages and platforms available for mobile devices. The .NET platform does this well, so we’ll use Microsoft’s C# and the MVC server-side framework.
To coincide with today’s need to provide important data and functionality for third-party integrations, we’ll layer code with clear breaking points for tiers, good reuse, and at least one sample, RESTful endpoint alongside our regular controllers in the sample application.
Maintaining database neutrality is a great idea in principle, but presents limitations in practice. Performance and other concerns often make it hard not to leverage stored procedures and other vendor-specific details of SQL database implementations.
This much is certain: our attempt to meet the goal entails that we leverage an object-relational-mapping (ORM) tool of some kind. Given the prior choice of the .NET platform and C# as a development language, the obvious choice is Microsoft’s Entity Framework, given all the LINQ-based expressivity it supports.
We’ll structure our sample application so that it would be easily possible in the future to break off the data tier and host it separately from the business logic. This kind of flexibility isn’t necessary for many web applications, but if you’re supporting a lot of users the ability to share data can be cost effective if you build in support for it from the outset.
English may be something of a de facto language for the web, but users increasingly expect products available in their native languages. Our sample doesn’t need translation, but our architectural and design choices need to take this into account from the outset to be relevant.
Thankfully, today’s web technologies make this easier than ever before. We’ll stick with the usual encoding (UTF-8) but won’t take any particular steps to segregate strings or handle their translations for now. The painful truth is that the details of proper multi-lingual support spill over into every layer of an application.
Supporting multiple deployment modalities is all about getting your build scripting right, having solid packaging options, and then selecting the right kind of infrastructure management (IM) tools. For our sample application, our IM discussion can wait; we’ve got bigger fish to fry for now.
Next, we’ll be building our sample application with an eye toward running in a simple web farm deployment, so that we can either deploy locally or to a cloud service with little effort to switch.
Finally, we need to develop our application as quickly as possible. Other than leveraging open-source software (OSS), we will use several other third-party tools:
- Microsoft’s Entity Framework:a database ORM tool
- Newtonsoft’s JSON toolkit: easy translation with our REST API
- NUnit: simplifies unit test development and running
- Rhino Mocks: generates mocked interfaces for unit testing
- Log4Net: logs messages and easily captures similar data
This list is hardly exhaustive; in fact, it’s a pretty trivial beginning for most projects. The key point for our DevOps focus, however, is that our sample will need support for consuming a wide variety of popular, third-party .NET assemblies, along with the component-based development (CBD) headaches this can bring.
Next week we’ll set up our version control platform, development environment, and continuous integration tool. Stay tuned!
You Ask, We Answer
As I previously mentioned, this is your roadmap to creating a successful DevOps pipeline. Don’t understand something? Just ask. Need to dive a little deeper? Send an email to [email protected] with your questions. Then, stay tuned for a live Q&A webinar at the end of this series.
Get DevOps Digest Sent to your Inbox
Subscribe to our 25-week DevOps Digest and we’ll send you a new post in the series every week. You'll learn everything you need to know about DevOps, one email at a time.
Catch up on DevOps Digest: