DevOps Digest 203: Creating a New Application in Helix
Last week in DevOps Digest 202, we made sure failure would NOT be an option, by setting up your development environment with the right tools, such as Visual Studio and Jenkins, for DevOps success.
With all the work we’ve done, it’s time to do some actual coding and start seeing some payoff. So let’s create a new application and get the source code under version control.
It would be easy enough to fire up Visual Studio 2015 (VS2015), select a project type, supply a directory, pick a few options, and let it generate files in its preferred folder structure. However, it’s useful to organize things a little differently because good product folder organization can pay significant dividends later and keeps our new web application separate from our solution. Sidestepping VS2015’s automatic setup, we’ll manually create a new solution and a new project before finally entering Helix.
Click on the corresponding links below for detailed, technical instructions to:
1. Create a New Solution
In VS 2015 a solutionis a collection of projects.
The first step for our sample is create a blank solution. In VS2015 terminology, a solution is a collection of projects, whereas projects may be web applications, class libraries, or a variety of other things. Start VS2015 and choose “File > New Project…” (Ctrl + Shift + N). In the New Project dialog, on the left, find the “Visual Studio Solutions” node under “Other Project Types”, and choose the (only) option to create a “Blank Solution”, as shown below.
2. Create a New Project
In VS2015, projects can be web applications, class libraries, or a variety of other things.
With our solution file in our preferred location, it’s time to create an actual sample project. Invoke the New Project dialog again, either by using the menu, keyboard shortcuts, or right clicking the solution file and choosing “Add > New Project…” from the context menu. This time choose an “ASP.NET Web Application” from the list of projects. Give it the name “DevOpsWeb” and note that we’ve specified an “Applications” sub-folder (that doesn’t yet exist) in the location field as seen below:
Again, this additional organization isn’t required, but it helps keep all our new web application separate from our solution. And these different conceptual entities will subsequently be kept apart from other important things like libraries, test suites, etc. Good product folder organization can pay significant dividends later, which is why we’re sharing the scheme most helpful when working with .NET applications.
3. Add an Ignore File
Before we make our first commit to Helix, there’s one more file to add: an ignore file. For those unfamiliar with this concept, the short version of the story is that an ignore file simplifies interactions with your VCS by preventing you from accidentally versioning things that shouldn’t be versioned. Compilers and other tools are notorious for creating all sorts of files during their processing, many of which we don’t want to version. Or at least not yet, though later articles in our series will discuss the value of storing certain build artifacts in our VCS.
4. Create a New Depot
Next, we want to store and version our sample project in Helix; the first step is to create a new depot. Again, this is not a required step; Helix is the one system that can keep all your content in a single depot if you like. But to illustrate how to create new depots, and particularly how to use the powerful streams features in Helix down the road, let’s walk through the process. Start the Helix Administration Utility (P4Admin), which was installed with the Helix Visual Client [directions in this article: DevOps Digest 202: Setting up for Success. You’ll see something like the following screenshot after you navigate to the “Depots” tab.
5. Create a Mainline Stream
Now that we have a streams depot, let’s create a mainline stream for our project. Streams are a helpful tool for mainline or trunk-based development, which we’ll demonstrate later. For now, we need a stream where we can store our sample application. With Helix Visual Client (P4V) launched, choose the “View > Streams” menu option (Ctrl + 7). This opens a new tab on the right titled “Streams”, which will show you that there are no streams available because we don’t yet have any.
Right-click in the pane that says “No streams selected” and choose the “New Stream…” option from the context menu (Ctrl + N). As you can see in the screenshot below, we’ve named it “Main” and kept it in our newly-created “DevOps” streams depot. Be sure that the stream type is set to “mainline” (which it will be by default) and uncheck the options to create a workspace or populate the mainline immediately. These options can be convenient, but we’ll introduce you to some other key concepts.
6. Create a Helix Workspace
The “Main” stream is empty, so the next thing we need to do is create a workspace to submit our first batch of content. Again, this isn’t strictly necessary as we could use DVCS features to commit and push our content right from the existing folder structure, but a Helix workspace can be a powerful ally. It’s worth learning a bit about them and how to create one.
Choose “View > Workspaces” from the menu (Ctrl + 5) and a new “Workspaces” tab appears on the right. To create a new workspace, right-click in the empty pane and choose the “New Workspace…” from the context menu (Ctrl + N). The following dialog appears (where we've already entered details):
We’re using the name of our workspace to indicate both the project in question (our DevOpsSample) and the stream in which we’re working (Main). This is not a good convention for everyone, as Helix makes it possible to switch streams back and forth within a single workspace as needed. For the purposes of a build server, however, it’s often a good idea simply to enforce a one-workspace-one-build-stream sort of mapping. Whatever convention you prefer, we’ll use this new workspace to add our existing files easily.
7. Submit the Default Changelist to Helix
All that remains is to submit our default changelist to the Helix server, so our work is safely stored and versioned. Select the default changelist and then right-click and choose “Submit…” from the context menu (Ctrl + S). This brings up the “Submit Changelist” dialog, in which to provide a suitable description, as seen below:
After completing steps one-six, we have a sample application stored in our version control system, so we’re ready to use our installed instance of Jenkins to build it. Stay tuned for issue 204 next week!
You Ask, We Answer
As 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 firstname.lastname@example.org 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 23-week DevOps Digest and we’ll send you the next post in the series every week. You'll learn everything you need to know about DevOps, one email at a time.