I recently read this article on The Atlantic: http://www.theatlantic.com/magazine/archive/2016/05/my-secret-shame/476415/ . While I am not one of the majority discussed in this article*, the ideas about the shame revolving in talking about money were not lost on me. I've been thinking about another secret shame that we are not supposed to discuss: the shame of being fired.
In March of this year I got fired for the first time in my professional career. Not "laid off", not "right-sized", just good ole "This isn't working out so we're getting rid of you.", fired. The actual details are seldom up for discussion for legal reasons, but as I began the dance of having meetings and interviews, I realized there is tremendous stigma around even simply admitting that there was an abrupt change and I wasn't the one who initiated it. I have collected a few thoughts around this:
Given the ever-increasing recognition of the power of Culture in business, it should shock no one to admit that not every person is a fit for every culture. Saying that there was a lack of alignment should be accepted as a serious issue, but not one that means you're an untouchable troublemaker.
Don't try to un-pull the trigger. During my meeting, thousands of thoughts quickly went through my head around how this action wasn't right, how I was doing what I needed to be doing, how much value I was adding, this must be a mistake, etc. No matter how you got there, if you find yourself with HR in the room looking at walking papers, the time for negotiating is past. Walk out respectfully with your dignity as intact as you can.
I loved the end of this article (https://plus.google.com/110981030061712822816/posts/AaygmbzVeRq) about presenting to Jeff Bezos, particularly where he surveys the room and realizes how terrified the VPs are of losing their position; they wouldn't laugh, smile, or offer an original thought until they were given permission by The Dread Pirate Bezos. If, like me, you agree that that sounds like a horrible way to live, then you have to accept that by taking strong positions and defending them, you may eventually get fired if the organization doesn't come around to your way of thinking. This isn't necessarily a bad thing. Don't give in to the scarcity mentality that you'll never have it this good someplace else.
Resist bitterness, especially public bitterness. Letting bitterness leak out just makes you look like poison. The first thing I did was go to Facebook and LinkedIn to let my network know that I was suddenly on the market, and wish the company and the senior leadership well. Despite irreconcilable differences in perspective, the business was undeniably on a vastly improved trajectory compared to the previous owners. I have no desire to see anyone, let alone an entire business fail. Don't embrace the scarcity mentality that someone has to fail for someone else to succeed: find your success out there.
Resist gossip and ask that your contacts do the same. This one was hard for me. Obviously you have to be curious as to how things are going and what's being said about you. Don't be, nothing healthy can come from it. After a while I had to just gently ask my friends and colleagues to stop sharing their concerns with me or asking for my advice regarding the company or specific efforts I had been involved in. While this is a normal activity among friends in the same line of work, it seriously interferes with a clean break and your ability to focus on healing and looking for what's next for you. Let it go.
Don't unfriend, unfollow, or blacklist people. Again, don't do things that make you look like a bitter crazy person. Don't send people the message that just because they're not on your team anymore they have no value as a human.
Look for the lesson: There may be a lesson. If you are not naturally an introspective person, this may be a wake-up call that you need to start evaluating yourself and try to gain the ability to self-correct. If you are naturally an introspective person, you may need to think about what has been missing from your habit of self-inspection. You may decide that you had improperly weighted the relative importance of priorities, that you had misjudged the political landscape, or just said the wrong thing at the wrong time. Search for the teaching moments.
Give yourself permission to be right: This is a hard one, and I hope no one misinterprets this point as arrogance (or self-delusion). There may be lessons learned that you can internalize and learn from moving forward. There may not be.
Give yourself permission to be hurt: Let's face it, in America our sense of self worth is often closely tied to working, making money, and what our title is. Even if you've been wise enough to save enough that this doesn't hurt you financially, it will probably hurt you emotionally for many of the same reasons I listed under "don't try to un-pull the trigger." No matter how appropriate the action may be, it's going to affect you, and that's OK.
Let’s face it, understanding Git is hard. And it’s hardly fair, really; up to this point, you’ve already learned a variety of different coding languages, you’ve been keeping up with what’s on the cutting edge, and then you find that Git has its own mess of terms and words!
So, we asked you, our Twitter community, “What is the hardest thing to learn about Git?” Here are our answers to some of the responses we received.
@GitKraken dunno about the hardest, but the most important is grokking the concept of the local repository. #LearnGit
— Uri Goldstein (@urig) August 18, 2016
Well, here’s the thing: you have to remember that your local repository is simply a representation of the remote. Think of it this way: imagine you took a snapshot of a beach or a landscape and then put the photo away in a drawer to take out every once in awhile to enjoy. But in reality, that beach or landscape that exists in the world is always changing. What you have in the drawer is just a concept of the real place.
It’s important to remember that you pull information from the remote repository, and what is on your computer (your local repository) is just a representation of the information you pulled down at that time.
So even if things change on the remote repository, they are not changing on your local repository until you pull those changes back to you. You simply have a copy of the repository at the time you pulled it. As other people are making changes on it, they are not reflected on your local repository until you pull those changes down.
Once your grasp this idea, it will become second nature. Just remember: “pull before you push.”
Yeah, about that… sigh. Let’s dig in: the difference between `git reset` with soft, mixed and hard is basically the following: soft leaves both your working directory and your index untouched. hard resets all your work.
@GitKraken merge conflicts, reset concepts. #LearnGit
— alexmaday (@alexmaday) August 18, 2016
What that means is that anything you had staged/unstaged stays where it was and all the changes between your previously checked out commit and the reset-to commit are put into staged. mixed leaves your working directory untouched, but resets your index to that commit.
Basically, it resets you to that commit and then unstages everything, regardless of what you had staged.
hard resets everything. Any work you had in your working directory is blown away. To be clear, that means all commits on your current branch that aren’t held in the history by another commit, either remotely or locally, are also lost (short of using some Git reflog voodoo).
For beginners, the difference between soft and hard is the most important distinction to make.
@GitKraken the concept of rebasing can be hard
— Josh Medeski (@joshmedeski) August 18, 2016
This is best explained visually. Check out this super short video that explains it all. Special guest Chris Bargren, GitKraken Dev, walks you through it.
Let’s deal with this on a case by case basis. Yeah, most times you can talk it through and work it out. Sometimes, sadly, you have to say goodbye and start from scratch. Yes, I’m talking about your relationship and Git.
Dealing with merge conflicts #LearnGit @GitKraken
— Brandon (@brandonscript) August 18, 2016
A merge conflict occurs when you try to merge two branches with changes on the same line of the same file. For example, file “A” changed in one area and also changed in another area. If the change exists on two different lines, it’s no sweat. However, if the change is on the same line, we have a problem, and now it’s up to the user to decide what to do.
Fortunately, there are tools that can help you in different capacities (short from couples therapy). Most Git clients and the CLI will tell you when there’s a conflict, and dedicated merge tools will help you edit those changes.
However, GitKraken’s interface shows you where the conflicts are and asks you how you want to merge, in a very visual way. In GitKraken Pro, you can not only merge gracefully, you can choose the affected line and edit it without getting out of the tool. No painful breakups today, my friend!
I get it. You love the CLI. You can see all the commands working underneath the hood, or covers, or whatever metaphor you want to use. You say you’re just wired like that. Ok, that’s cool. Aside from time and training, there’s not a lot that can be done to speed up the process of learning it. In GitKraken, we make it so you don’t have to see what commands are happening.
You heard that right. You don’t need to know every command in order to get the job done, and I’m here to tell you that’s not a cop-out. You’re not less of a dev. Now, go look in the mirror and tell yourself that.
@GitKraken #Git #LearnGit not having a decent Linux git Gui to support command line learning. #GoGoGitKraken
— Jonathan Storey (@jonistorey) August 18, 2016
GitKraken aims to make it so you don’t need to know everything that is happening “under the hood”. You don’t need to have it in your brain that you are running Git rebase branch A and branch B. You don’t have to remember that the command to take back that last commit you accidentally made is git reset --soft HEAD~1. You just right-click that commit and Reset -> Soft. You don’t have to dig through the output of git reflogto undo that accidental git reset --hard. That’s a simple click of the undo button.
So, if you’re starting to think that there might be a better way; that the CLI might not be the be-all-end-all; that maybe there is one special GUI that could pull you away from the CLI. We want to tell you: it’s okay! It’s okay to want to get work done quickly and efficiently and save some of your memorization skills for party games. You’ll find that doing work in GitKraken is actually easier (and come on, who doesn’t want that?)
Other Git GUIs may have burned you in the past, because yes, while they do make the work more straightforward, it’s not necessarily faster. We dare you to give GitKraken a try, and see if it’s the one!
By this point, you’ve probably heard that Team Foundation Server 2015 has a completely new build system. As part of it, it organizese and compiles the code slightly differently than the old XAML-based TFS Build system. First off, when you run a vNext build on a build server, you got four folders: a, b, s, and TestResults. TestResults contains (surprise!) the results of any unit tests that you ran. The “s” directory contains the source code that went into the build. The “a” directory contains the artifacts (also known as the “drop”) that are uploaded at the end of the build. The “b” directory is probably empty.
The disk layout for a TFS vNext build
If you’re in a DevOps mindset and you’re trying to deploy an ASP.NET Web Application (WebForms, MVC, WebAPI), you’re probably going to panic when you open up the artifacts directory (“a”) and find everything EXCEPT your web application. If you’re used to doing “right-click deploys” or you’re used to building with the old XAML-based TFS build system, you’re probably wondering where your nice _PublishedWebsites directory is. Life used to be so easy. You used to be able to do a simple copy/xcopy from _PublishedWebsites and you were done. Now that directory’s gone and — well — that’s kind of annoying, isn’t it?
There’s a reasonably straightforward fix.
Go to your build definition. Click on the Visual Studio Build task. By default, that’s the second task in the list.
Next you’ll need to specify some additional parameters for the MSBuild Arguments value for the task. These parameters cause the web project to do a file system deploy that’s pretty much the same thing that it would have done to create that _PublishedWebsites directory. To make your life easier as you get into more and more build and deployment customization, I’d recommend creating a ‘for-deploy’ directory inside of your artifacts directory and putting the published code in that.
Here’s the value to paste into MSBuild Arguments. This will publish the website into a directory called “for-deploy\website” in the artifacts directory.
/p:DeployOnBuild=True /p:DeployDefaultTarget=WebPublish /p:WebPublishMethod=FileSystem /p:DeleteExistingFiles=True /p:publishUrl=$(build.artifactstagingdirectory)\for-deploy\website
Edit the MSBuild Arguments for the Visual Studio Build step
After you’ve plugged that value in, save the build definition, and then run a new build.
When the build completes, click on the Artifacts tab to view the build’s drop. Remember: this drop directory is the same as the contents of the artifacts directory at the end of the build. Click the Explore link to take a look at the artifacts from your build. 
The Build Artifacts Tab
You should now see the Artifacts Explorer dialog and if you expand the folders, you’ll see the for-deploy\website directory. Inside of that directory is the published website that’s ready for you to deploy to your web server. 
Artifacts Explorer & the Build Drop
I hope that this saves you some pain and frustration.
-Ben
— Looking for help getting going with Team Foundation Server Build vNext? Want to get better at DevOps? Not sure where to start? We can help. Drop us a line at info@benday.com.
I’ve been doing a bunch of work with the new version of Build and Release Management in Team Foundation Server 2015 (TFS2015) lately and discovered a handful of things that I wish that I could do from the command line. Specifically, I wished that I could import and export my build definitions and release definitions. Well, a couple years back, I released a set of command line utilities for Team Foundation Server so I decided to do an upgrade and add some new features.
The new features:
With these new features you can export and share your build and release definitions between TFS Team Projects and servers.
The utility still has the original features, too:
Here’s a link to download the utility. Here’s a link to download the source code.
-Ben
— Need help with your TFS Builds? Not sure where to start with TFS Release Management? Want to get good at DevOps? We can help. Drop us a line at info@benday.com.
Problem:
When I try and install my agent as a service with a user account it fails to start.
Even if I try to start it from services window it fails.
Solution:
Make sure the account has the “Log on as a service” right.
Explanation:
After configuring my agent with the following command my agent failed to start.
.\config.cmd --url https://<Account>.visualstudio.com --auth PAT --token <token> --pool default --runasservice --windowslogonaccount <DOMAIN\USER_NAME> --password <MyPassword> --work _work --agent <AgentName>
Windows services begin to run as soon as Windows boots regardless if anyone logs into the machines or not. Therefore, any accounts used as the service identity must have the right to log on as a service. I needed to run my service as a user account because package management systems like NPM install packages per user. Those packages cannot be used by the Network Service account so I configure my service based agents to run under a user account.
To correct this you have two options. Your first option is to do everything from the Services window.
Your second option is to manually grant the Log on as a service right using Group Policy.
net start “VSTS Agent (<account.agent Name>)”Replace <account.agent Name> with your information
Log in
