You can perform static code analysis to verify your code doesn’t include major vulnerabilities. You can run a linter if you’re nitpicky like I am and want to ensure new changes are formatted correctly. You can run unit tests to be sure the new code you wrote did not introduce regressions. You can deploy your web app to the cloud. You can create an installer for your desktop app. I could go on but will instead just repeat: the coolest and niftiest parts of app dev.

I should briefly note that the full definition of CI/CD (like Wikipedia notes here) defines that it can be considered more of an execution style: where CI is the frequent merging of several small changes into a main branch, and CD is the production of software in short, efficient cycles so that it can be continuously delivered.

While frequent integration of code into the main branch and the delivery of new features are very important, any references to CI/CD in the remainder of this blog will refer to the concepts of automated code validation and automated code deployment (via CI/CD pipelines).

Into the Nitty Gritty

Here’s some clarifying information before I rave further about CI/CD pipelines:

Continuous Integration (CI) — focused on building and testing code as it is committed to the remote repository.

Continuous Deployment (CD) — focused on deploying and releasing software.

Why Should You Care?

CI/CD pipelines are super nifty but do require time to set up. Someone needs to write the code that can run automatically, right? If you’re on a project with a tight timeline, it can be tough to justify devoting extra time to configuring your web app so it can deploy automatically (especially when you could just deploy it using the Azure CLI yourself).

But what happens when you have multiple developers working on the project who also need to deploy their changes to the web app? What if you get pulled to another project and can’t manually deploy? What if you forget to run the unit tests before deploying and you deploy broken code to your site?

Writing a CI/CD pipeline is an investment into the long-term health and maintainability of your code base. Continuous integration can verify that new code is up to par (via static analysis, automated unit test execution, code coverage, and linting). If a developer commits code that can’t build or doesn’t pass unit tests, your pipeline will flag that there’s an issue.

Continuous deployment reduces the overhead of deploying your code base. It ensures that each deployment step is executed when new code is deployed (none are forgotten through human error) and that a single person doesn’t have the overhead of manually deploying the app each time code needs to be pushed.

Environments

Setting up a CI/CD pipeline can also make it much easier to support multiple environments for your application. In the past, I’ve set up ‘development’, ‘staging’, and ‘production’ branches in addition to ‘main’. I’ve then configured my pipeline to deploy to the appropriate environment when code is merged into its matching branch.

This makes it easy to determine which code is live for each branch or to generate diffs between environments. It also means that you can push code after performing a pull request to the appropriate environment: giving you the opportunity to review the code before it goes live.

An important note regarding production: be sure to configure appropriate permissions or gates for triggering your pipeline to production. Those gates could be rules on the pull requests that merge to a production branch or restricting permissions of the users who can trigger a branch that deploys to production.

A fun note: you can also use IaC to deploy the resources that host your application based on each environment, but that’s a topic for another time.

How to Configure CI/CD

Most source code repositories (i.e. GitLab, Azure DevOps, GitHub, Bitbucket) offer their own flavor of the yaml file required to configure a CI/CD pipeline. Their documentation will be the most helpful resource on the specific syntax required to make their yaml files run.

Overview

Writing a CI/CD pipeline is most likely worth your time if:

• You have multiple developers working on your code base.
• You want to automatically test code quality whenever a developer pushes to the remote.
• You want increased repeatability and reliability of your deployment processes.
• You want to reduce developer overhead when new code needs to be deployed.
• You want to support multiple environments.

(It’s also just super cool and nifty).

The post Intro to CI/CD Pipelines appeared first on DMC, Inc..

Fret not! This blog will walk you through generating an installer to install .exes onto a system using a Windows 64 bit processer. We will be using WixSharp, written by Oleg Shilo, to generate our installer.

A few notes before we start:

• The app I am creating an installer for uses .NET Core 3.1
  • WixSharp requires .NET Framework to run, therefore, you will not be able to reference a .NET Core application directly from your WixSharp project.
• This demo was created using WixSharp version 1.19.0, WixToolset version 3.11.2, and WixSharp Project Templates version 1.15.0.
• If you’ve already published your app, you can skip to the section Installing Wix Dependencies

Publishing Your App as A Single .exe

You can package your entire app as a single .exe. To do so, access your publishing settings by right clicking on the project you want to publish and selecting “Publish” from the drop-down menu.

You can use the settings shown above to generate a single .exe intended to run on windows’ 64 operating systems. Save your settings, and then click the “Publish” button in the upper right-hand corner of the Publish window.

This will generate a .exe and a .pdb file within the bin folder of your application at the path Release>{.NET version}>publish. You will only need the .exe to run your application; you can test this by copying and pasting the .exe to your desktop and running the .exe to launch your application.

Installing WiX Dependencies

Start by installing the latest stable version of the WiXToolset. Within the git repository, you can download the .exe listed within the project assets.

Next, install the WixSharp Project Templates. These will install within your instance of Visual Studio and allow you to generate template WixSharp projects, which helps to streamline development.

Add a new project to your solution, of template type WixSharpSetup. The other project templates provide other features, but, for the purposes of this example, we will use the basic setup project.

Once you’ve generated your project, install the WixSharp NuGet dependencies. To do so, right click on your new WiX project and select Manage NuGet Packages from the dropdown menu.

Installing the WixSharp package will automatically include the WixSharp binaries; you do not need to install them separately.

Once you’ve installed your dependencies, you can open the Program.cs file within your project. Remove the comments reminding you to install WixSharp.

Additionally, you can replace the Program class with the one shown below, which will display a custom UI for your user while installing your app (shown at the bottom of this blog) and installs the .exe within the system’s program files, as well as within the start menu and on the user’s desktop.

You will need to add two using statements to run the below code: using System.Linq and using WixSharp.Controls. Feel free to remove the comments as needed.

If upon building your project, you generate errors that look like the ones below, you will need to update your framework to match that required by WixSharp.

To do so, right click on your WiX project and select Properties. Here, you can update the framework to match the one noted in your error messages (in the case of the screenshots, .NET Framework 4.5.1.).

Once you’ve updated your target framework, you should be able to successfully build your app! The MSI will take a moment to generate; you will know your process is complete when a console window loads and then closes itself. At this point, you should be able to open your WiX project within your file explorer to find your brand new MSI!

Another common error you may run into can occur if you do not install the WiX Toolset linked at the top of this article. There is a WiXToolset NuGet package that is not the same as the WiX Toolset you need for this workflow. If your toolset is not installed, you may see a ‘WiX binaries cannot be found. Wix# is capable of automatically finding WiX tools only if WiX Toolset Installed.’

To fix this issue, install the WiX Toolset.

Now that you know the basics for generating an MSI file, you can customize your installer using the WixSharp library. You can create a custom UI workflow, update where your application automatically installs to, and much more. For examples of how to implement these functions, see the WixSharp git repository.

Running Your Installer

You can now run your installer and install your application!

Learn more about DMC’s Application Development expertise, and contact us to get started on your next project.

The post How to Generate an MSI using WixSharp appeared first on DMC, Inc..

Each month, a different office gives an update at the end of the meeting. During the month of September, the Houston office was tasked with updating the world of DMC about the goings-on in the 713.

DMC Houston has been busy since our last update. We worked on a ton of different projects, floated on boats, lost John Williams to the new Dallas office, welcomed new hires, and moved into a shiny, new office. We chose to show off our new space with a spoof of the sorely missed MTV show, Cribs. Some of the perks of our new office include a pristine new kitchen, a new lab, and most importantly, lots of Topo Chico.

I could go on for pages about our new office, but I’ll let our update video (and our gracious host, Kevin) do the rest of the talking.

Check out our update video below or on YouTube with the rest of our office update videos. 

Learn more about DMC’s Company Culture.

The post DMC Houston Office Update: Welcome to Our Crib appeared first on DMC, Inc..

Painting Party

New hires all start by training in Chicago before moving to their respective office locations. I had a great time being welcomed by the Chicago crew along with other new employees at an interactive art exhibit called the WNDR Museum.

Once I arrived in Houston, the team here took the opportunity to welcome Cody Cook and me. For our welcome party, we hosted a Bob Ross painting night!

We painted along to Bob Ross’s "Southwest Serenity" video and ordered Thai food. We also got a good spread of snacks and drinks. Several of us opted to take our first shot of Malort (a Chicago-based spirit), which was definitely an experience.

Artsy Engineers

Once we finished painting. we were able to send all of our extra supplies (easels, canvases, acrylic paint, brushes, and paint container pallet things) home with Maddie’s roommate, who’s an art teacher.

My favorite part of the whole welcome party was getting to see everyone’s artwork at the end (especially Leigh’s). All the paintings actually turned out really well!

The painting party was a fun way for our engineers to show off a different set of skills. It was great to spend time getting to know my new colleagues. Bob Ross has some competition from a few of DMC's engineers!

Learn more about DMC's company culture and check out our open positions to join our team.

The post Houston Welcomes New Employees with a Bob Ross-inspired Painting Party appeared first on DMC, Inc..