Page 6 of 7

Deploying with MsDeploy Outside of Visual Studio

Building the msdeploy package with MSBuild.

This requires MsDeploy to be installed on the build machine.

MSBUILD /T:Package /P:Configuration=QA;PackageLocation="C:\Build\Artifacts\eserve\DEV\QA\QA.zip"

Deploying the package with MsDeploy to a web site

How to get the msdeploy command.

-source:package='C:BuildArtifactseserveDEVQAQA.zip' -dest:auto,ComputerName='https://eserve-dev.sacda.org:8172/MsDeploy.axd?site=eserve-dev',UserName='conwayc',Password='austin_1',IncludeAcls='False',AuthType='Basic' 
-verb:sync 
-disableLink:AppPoolExtension 
-disableLink:ContentExtension 
-disableLink:CertificateExtension 
-allowUntrusted 
-retryAttempts=2

Copying the package with ROBOCOPY

Copying the package to another folder with robocopy has an issue. Robocopy uses exit codes as success/error codes. CI servers look at the exit code of a command to determine success or failure. Robocopy breaks this model. Luckliy the sql team posted a code snippet to get around this issue.

rem http://weblogs.sqlteam.com/robv/archive/2010/02/17/61106.aspx
robocopy %*
rem suppress successful robocopy exit statuses, only report genuine errors (bitmask 16 and 8 settings)
set/A errlev="%ERRORLEVEL% & 24"
rem exit batch file with errorlevel so SQL job can succeed or fail appropriately
exit/B %errlev%

Deploying from folder to site

-verb:sync -source:contentPath=C:BuildArtifactsSSOClientDEV -dest:contentPath="C:inetpubadfsls",computerName='http://customer.dev.myconsolidated.net
/MsDeployAgentService',userName=ccadmin,password=$urewest123

Change App Path at Commandline via MSBuild

/T:Package 
/P:Configuration=DEV;PackageLocation="C:\BuildArtifacts\Grover\Dev\Builds\DEV\Grover.zip";DeployIISAppPath=dev.grover.winnemen.com

Using MsBuild to deploy contents to folder

/T:PipelinePreDeployCopyAllFilesToOneFolder /P:Configuration=QA;_PackageTempDir="C:Build\Artifacts\Momntz\DEV\Builds\QA

Deploying Local with MSDeploy

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:package='C:\BuildArtifacts\AlSupport.zip' -dest:auto,computerName='localhost' -allowUntrusted -retryAttempts=2 -verbose

Deploying folder to Azure with MSDeploy

The following command line is for deploying a folder to windows azure websites.

"C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe" -verb:sync -source:contentPath="C:\TeamCity\buildAgent\work\d018513aed1c09f\Build" -dest:contentPath="groverqa",wmsvc=waws-prod-bay-005.publish.azurewebsites.windows.net/msdeploy.axd?site=groverqa,userName=$groverqa,password=secret,authtype='Basic' -AllowUntrusted

All UTC times are not necessarily the same

A friend pointed out that all UTC Time is not the same. When he told me, I responded with “What!?! What are you talking about? It’s the same.” “No it’s not” he said. He explained, that yes using UTC will allot you an agreed upon time format but that does not guarantee that both server’s clocks are synchronized.

For example, Sever A calls server B for updates. Both Servers use UTC Time. Server A sends over a timestamp, how do we know that the two servers clocks are synchronized and that the two times match, we don’t. The odds are they are not. How can they be? Absolute time does not exist. It’s all relative. By using a timestamp to retrieve data from another server you are making an assumption that both servers have the same time.

*photo reference

2 minutes on Migrating Data

I had a great talk with my friend Dave today. He’s a Data Scientist. He knows his stuff, for sure.

We talked about a number of things, but one that really stuck out was data migration. He says never to migrate via code, use a tool. You are reinventing the wheel. You are locked into your solution. All the risk is in your court. And the solution is not flexible. With that said. He went on to say the most efficient way to move data is with a primary key and a hash.

The destination side will request all the primary key and row hash. Taking the primary key it will check if the row exists. If it does exist it will compare the hash of the source to the hash of the destination row. If they match then the process is repeated for the next row. If they don’t match, then the primary key is added to a list of rows to request from the source. If the primary key does not exist then the primary key is added to the list of rows to be retrieved from the source. When the row comparison is completed all the rows that are stale or do not exist are requested from the source and persisted to the destination.

Grunt

If you enjoy grunt work you’ll do the above. If you are a developer who enjoys building robust applications you’ll leave the grunt work to the tools.

Chronic Contractor

This developer is always looking for a gig. There is always something better. Chronic Contractors are expensive. Mileage per dollar varies.

They have battled many and because of this they see problems. Something about every gig frustrates them.

Chronic Contractor tend to work in cutting edge technologies and loathe older “inferior” technologies. They have no allegiance, they don’t care if the ship sinks, another is waiting in the docks.

Insecurinator Developer

This developer refuses to find a better job. They have had only one job, and they will not leave it — It’s the only breast they have fed from.

They are treated poorly, paid next to nothing yet they refuse to look for greener pastures. They have an unlimited supply of excuses; they may even in principle agree to find a new job, but they never will.

King of the Hill Developer

Typically this developer has been in few organizations. They tend to be the smart frog in the small pond. When another smarter developer joins them, they try to subjugate them. Tactics include withholding information, passive put downs and excessive explaining.

King of the Hill Developers have all the answers, similar to the Go To developer, they have the grand scheme in their minds and only give information as needed. When idea’s arise that are better or will make them look bad they vigorously deny the validity of the idea.

Since they work in a royal vacuum, their designs and code tend to be flawed.

The Ego Interviewer

You’ll begin the interview and the questions won’t feel right. They’ll be extremely technical border lining on absurd or they’ll be edge cases, in either case, specialized knowledge is required to answer correctly. The questions are a setup for failure and an opportunity for the interviewer to stroke their ego. In fact, the entire interview has little or nothing to do with the position. It’s all about the interviewer taking a hit off the validation crack-pipe.

Similar needy behavior will occur on the job. The Ego Interviewer will not hire someone who is smarter than them. They can’t have someone proving them wrong. They desire to be the smartest guy, the “go to guy” (an anti-pattern) of the group. Once they’ve decided they are smart and you are not, The Ego Interviewer will insist on explaining everything to you in the minutest detail. Again this is another strategy to display their intelligence and superiority.

The Ego Interviewer does not create a cohesive work environment, most developers in these environments will be on edge. The developers are secretly hoping the Ego Interviewer will be sick today.

The Ego Interviewer will continue to passively step on you to stroke their ego. If you challenge them they’ll stop at nothing to quell your defiance. They only way out is get them replaced or move to a different team.