Too many cooks in the SharePoint kitchenJune 19th, 2012 | Author: Scott Rooke | Filed under: CloudShare, Dev / Test, SharePoint | Tags: CloudShare, demo, Development, project management, SharePoint, silo, snapshot
Recently as I was working in my CloudShare “development” environment, I ran into a situation that all developers have run into at one point or another. The client says to you, ”hey, I’d like to be able to see how it’s coming along.” Seems all well and good so you create a login account and they begin to poke around. This is when it hits you, “oh my gosh, how do I get them out of the kitchen?” They want to watch the water boil, open and close the oven door to check on how things are coming along. This is when panic sets in because you then realize, there is no way I’ll be able to keep moving forward while they are in poking around and asking questions why this doesn’t work or that doesn’t look right. The problem with this is, sometimes when something “doesn’t work” it is not because it is broken, it just hasn’t been implemented yet. So you spend the next several days trying to fix things, out of order, and you don’t make the progress you were on track to do.
So what do you do? This is what happen to me and I began to think about ways around this. First I thought, “hey, I could stand up another CloudShare server and deploy my code updates to it and when building solutions on SharePoint there are more than just code updates. So the reality of trying to setup a true content, configuration and code deployment environment and process seems like it could be more effort than it is worth at this point. Ultimately, yes this is a preferred method but when you are trying to get something stood up and prototyped quickly this is a lot of additional effort.
At this point, the wheels started spinning in my head. I thought, “what if I were to take a snapshot of my current ‘dev’ environment and the restore it to a ‘new’ CloudShare environment when I am ready to share changes with the client Hmm….” And as I thought about it more it became clear this was the way to go. So I tested it out. It just so happened that this happened on the same day that the “Vanity URL’s” product feature became available. How perfect for me. So here is what I did:
- Created a Snapshot of my “Development” environment
- Purchased another CloudShare environment
- Restored the Snapshot to the new environment
- Once the environment was restored, I noticed that AD user account passwords were reset. That was okay because I only had a few accounts in AD so it wasn’t that much to reset their passwords.
- Created 2 new Vanity URL’s
- Assigned these new URL’s to each environment respectively.
- Updated Central Admin – Alternate Access Mapping (AAM) with the new Vanity URLs
- In my case, I had to also update Search to use the new URL when displaying search results.
And that was it. I now have a safe place for the client to poke around and look, while at the same time not having them ask questions why something isn’t working because you are working on it and it is purposefully broken. The best part about this is, it is a repeatable process that can be done quickly without much effort in the background while continuing to work.
I must also give a SHOUT OUT to CloudShare for providing an excellent product and GREAT customer service. They have always been quick to respond to any questions or issues I’ve had. Way to go!!!!
This has also been posted on my blog – here.