BrandonBarnett.io

How to write code like a consultant

2021-02-12T00:00:00+00:00

As software development continues to grow with the world around us and offers more stable and lucrative opportunities, new developers might wonder how to differentiate themselves in an industry that is fairly homogenous and stereotypical. How do you break the mold and stand out from your peers to find more success and happiness in your career?

I have been working with development teams for over 10 years, including people of all shapes and sizes. My previous few jobs were in consulting, which means I always had clients who dictated what success looked like. Lately with Phoenix Sports Partners, it is up to our product teams and me to define what that means. The theme I have seen throughout for developers who have stuck out to me has come down to their ability to think critically and be consultative - they are thoughtful, ask good questions and are good communicators. They also are detail oriented and have good code hygiene.

This is an example of how a standout developer would take a feature from story-to-production:

Read the story title and description (and acceptance criteria if available). Think through what you interpret to be the problem and ask clarifying questions if you find any ambiguities. Remember: you are more than a story-to-code translator - it is up to you to determine the full scope of how to meet the objective of a user story. Make sure you understand what the story is trying to accomplish and why. This will influence your ability to find edge cases.
Branch from the latest commit on the develop branch (make sure to pull first). This is important because it will ensure there are no other unrelated changes in the branch. I occasionally see unrelated changes which makes it difficult to test code.
Write some code, test thoroughly. Make sure you’re thinking through edge cases at this point to ensure you don’t have to return to this work later when bugs are filed.
Push your branch.
When it comes time to create the PR, please review your own code before submitting. Sometimes things get missed locally in your commits that need to be tidied up before PR creation (e.g., commented code, commits accidentally included from other work).
I am not overly strict about encapsulating your changes to ONLY what’s written in the story. However, please help me out by explaining any changes that aren’t obviously connected.
Any code that is not self documenting needs to have code comments. Any PR changes that are not self evident (e.g., are not a part of the story/AC) need to have source control (GitHub, BitBucket, ADO) comments from you to explain. The goal is that a reviewer should have all the context available in the PR to review your code without needing to ask follow up questions.
A PR is meant to represent code that you think is ready for production - it’s not a staging area. If it’s not ready, it should not be in PR.
Test all changes once deployed to the first higher-level environment. Typically for me out of my develop branches that is a Dev environment.

Throughout this process, always be thinking through the end user experience, and never hesitate to ask questions. I would so much rather field lots of questions than have to throw away or create rework later because we weren’t completely aligned on what you’re supposed to be doing.

Should you generalize or become an expert?

2019-08-12T00:00:00+00:00

What is better for your career: spreading your learning time across many subjects at a surface level or going all in on 1-2 topics? Check out my video to see what I think!

Leaving features behind

2019-08-09T00:00:00+00:00

Every project has constraints; be aware of what they are, and be relentless and practical in your approach. Don’t make too many assumptions on your customers’ behalf by overloading your product with your favorite features.

How I keep current with tech

2019-07-16T00:00:00+00:00

We all have a lot to do! How do I keep current with technology - an industry where the only constant is change? Check out my video for how I keep up. How do you do continuously learn?

Simplifying with social vs technical constraints

2019-07-12T00:00:00+00:00

Our team has been working on a software product and - in an effort to simplify our investment - have come to categorize our requirements as social or technical constraints. Please watch my video and I’ll explain the concept and how it could help you!

How to start creating video content

2019-07-05T00:00:00+00:00

Lots of people want to create online content but for a variety of reasons, find that life gets in the way. Here are a few thoughts on how to actually create your first video!

The secret to painless software product releases

2019-06-30T00:00:00+00:00

During my time in consulting and product development, there has been one consistent theme throughout all of the best releases I’ve been a part of. Check out my secret to painless software product releases and reach out on Twitter @brandonbarnett if you have questions!

Creating successful products

2019-06-23T00:00:00+00:00

Four key thoughts on how to create successful products.

Why isn’t Azure App Service Deploy copying files to my Web App’s wwwroot?

2019-02-20T00:00:00+00:00

I was recently working with a collegue to deploy a Sitecore app to Azure via Pipelines. The release was running successfully, but the deployed files didn’t seem to be overlaying the required, pre-loaded Sitecore files. When we viewed /site/wwwroot from Kudu, we were seeing only the files from the build artifacts; when we viewed the same directory from FTP, we were seeing only the Sitecore files. What gives?

The cause: Azure App Service Deploy task version

Sometime over the past few months, the Azure App Service Deploy release task versioned to 4.*. In that release, the Microsoft team created an auto-detect feature that tries to guess the best method for code deployment to your Web App. In our case, it chose the new preferred method called Run From Package, which has a few quirks.

What’s new in version `4.*`

These are the new features in 4.* per the Azure DevOps UI at the time of writing:

Supports Zip Deploy, Run From Package, War Deploy
Supports App Service Environments
Improved UI for discovering different App service types supported by the task
Run From Package is the preferred deployment method, which makes files in wwwroot folder read-only
Click here for more information.

Most relevant for us is the Run From Package feature.

How does that work?

When the release task deploys using Run From Package, it does a few things:

Zips build artifacts and uploads to /data/SitePackages/.
Creates a /data/SitePackages/packagename.txt file whose contents point to the deployed zip filename.
Sets a new Application Setting to the app of WEBSITE_RUN_FROM_PACKAGE=1.

The effect of the WEBSITE_RUN_FROM_PACKAGE setting is that the /site/wwwroot/ directory now vitually points to the deployed zip file, not to the actual underlying file system. Try it: download the package zip from /data/SitePackages/ and compare contents with /site/wwwroot/ in Kudu. If you extract FTP credentials from the publish profile and access /site/wwwroot/, there is a completely different site of files. Here’s what I’m seeing from a fresh .NET Core MVC deployment:

Kudu

FTP

The solution

When Microsoft updated the release task, they made a major change to the default behavior of the task and hid the option under the Additional Deployment Options section.

When the Select deployment method option is not checked, the task appears to prefer the Run From Package option. Since I want to overlay my deployment files over existing files, the solution for us was to select the option and choose Web Deploy as our deployment method.

Web Deploy matches the previous behavior of the release task in that it overlays my build artifacts without removing any of the destination files:

I also noted that when I switched the deployment method to Web Deploy, the release task automatically set the WEBSITE_RUN_FROM_PACKAGE setting to 0, which disabled the /site/wwwroot/ mismatch we observed.

Accessing Azure Artifacts from a docker container in a Pipelines build

2019-01-17T00:00:00+00:00

In my previous post I talked about how our team is publishing NuGet packages using Azure Pipelines to a DevOps Artifacts feed. Now it’s time to consume those packages. There are plenty of examples on how to connect to a feed in Build, but our case is a bit different because our applications are containerized. The purpose of this post is to share specifically how we authorize access to Artifacts from a docker build context in an Azure DevOps Build.

Please see this Gist for full code references.

Security

The purpose of using Azure Artifacts is to avoid a public package manager because the team is writing IP into shared libraries. It should then come as no surprise that there are a few additional steps required to ensure that your docker build context has appropriate access to Azure DevOps.

The docker build context is isolated from Azure DevOps, meaning that it should be considered a sandboxed build that doesn’t share environment variables and access that typical Build tasks would. The trick to authorizing a docker build is to use a Personal Access Token as a rotatable key that tells Azure DevOps that it is authorized to pull packages from Artifacts. Start by creating a PAT: click your avatar in the upper right of DevOps then Security in the dropdown. Make sure it has access to Packaging.

Pipelines variable group

The next step is to create a group of variables that you can share between all Build definitions. I created an Artifacts group and added an artifactsAccessToken (this is your Private Access Token) and artifactsEndpoint which I got from clicking Connect to Feed from my Artifacts feed.

CI and CD builds

Go ahead and create your CI and CD builds and feel free to use my files as a template. Note that I am specifically passing in the variables I created in the variable group above using the following method:

...

variables:
- group: Artifacts

...

steps:
- task: Docker@1
  displayName: 'Build an image'
  inputs:
    ...
    arguments: '--build-arg ARTIFACTS_ENDPOINT=$(artifactsEndpoint) --build-arg ACCESS_TOKEN=$(artifactsAccessToken)'

This ensures that the variables get mapped to the Dockerfile ARGS that we also need to define.

Important: once you create the build in DevOps, you need to click through Variables > Variable groups and click Link variable group. This is a security feature and is a required step.

Dockerfile

Now that we have builds set up, create a Dockerfile that defines how your app is build and run. To use the variables we passed in via Build above, create ACCESS_TOKEN and ARTIFACTS_ENDPOINT ARGS to accept them. The key changes from a typical Dockerfile is that you need to install the Azure Artifacts Credential Provider and then set the NUGET_CREDENTIALPROVIDER_SESSIONTOKENCACHE_ENABLED and VSS_NUGET_EXTERNAL_FEED_ENDPOINTS environment variables to let it do its job. Also, alter your dotnet restore task to use the new feed endpoint.

Now run through the entire process and make sure everything works correctly. If so, you should have a new docker container image ready for deployment! Please reach out if you have any questions or a different approach.