Process:
1. Establish contact
a. Gather high-level description
b. Identify audience (i.e. everyone, line-of-business)
c. Define process (current process or something brand new)
d. Automation of manual process? New business model?
e. Who does this benefit? Authority? Budget?
f. Support Plan? Primary technical / business contacts?
2. Project Slating - Group Discussion
a. Decision point
b. Review scope of project
c. Develop Project charter
d. Review info gathered in contact phase
e. Is it related to something in environment already?
f. Is it a go, no-go?
3. Requirements
a. Understand project scope
b. Ideation
c. Analysis
d. Technical Assessment
e. Identify and document scope document
f. Given scoped-out detail, can we take this on? If so, create SOW.
4. Project Management
a. Define project timeline
b. Weekly update meetings
c. Customer facing / Team facing
5. Development
6. Closing Activities
a. UAT, Customer sign-off
b. Go gold -- move into Production
c. Implement support plan
Wednesday, October 20, 2010
Tuesday, October 05, 2010
Web Application or Web Site...now that's the question
For reasons why you should care about which one is used see: http://msdn.microsoft.com/en-us/library/dd547590.aspx
Scenarios in which Web application projects are the preferred choice include the following:
• You want to be able to edit code without stopping a debugging session.
• You want to run unit tests on code that is in the class files that are associated with ASP.NET pages.
• You want to refer to the classes that are associated with pages and user controls from standalone classes.
• You want to establish project dependencies between multiple Web projects.
• You want the compiler to create a single assembly for the entire site.
• You want control over the assembly name and version number that is generated for the site.
• You want to use MSBuild or Team Build to compile the project. For example, you might want to add pre-build and post-build steps.
• You want to avoid putting source code on a production server.
• You want to use the automated deployment tools that are available in Visual Studio 2010.
Scenarios in which Web site projects are the preferred choice include the following:
• You want to include both C# and Visual Basic code in a single Web project. (By default, a Web application is compiled based on language settings in the project file. Exceptions can be made, but it is relatively difficult.)
• You want to open the production site in Visual Studio and update it in real time by using FTP.
• You do not want to have to explicitly compile the project in order to deploy it.
• If you do precompile the site, you want the compiler to create multiple assemblies for the site, which can include one assembly per page or user control, or one or more assemblies per folder.
• You want to be able to update individual files in production by just copying new versions to the production server, or by editing the files directly on the production server.
• If you precompile the site, you want to be able to update individual ASP.NET Web pages (.aspx files) without having to recompile the entire Web site.
• You like to keep your source code on the production server because it can serve as an additional backup copy.
Scenarios in which Web application projects are the preferred choice include the following:
• You want to be able to edit code without stopping a debugging session.
• You want to run unit tests on code that is in the class files that are associated with ASP.NET pages.
• You want to refer to the classes that are associated with pages and user controls from standalone classes.
• You want to establish project dependencies between multiple Web projects.
• You want the compiler to create a single assembly for the entire site.
• You want control over the assembly name and version number that is generated for the site.
• You want to use MSBuild or Team Build to compile the project. For example, you might want to add pre-build and post-build steps.
• You want to avoid putting source code on a production server.
• You want to use the automated deployment tools that are available in Visual Studio 2010.
Scenarios in which Web site projects are the preferred choice include the following:
• You want to include both C# and Visual Basic code in a single Web project. (By default, a Web application is compiled based on language settings in the project file. Exceptions can be made, but it is relatively difficult.)
• You want to open the production site in Visual Studio and update it in real time by using FTP.
• You do not want to have to explicitly compile the project in order to deploy it.
• If you do precompile the site, you want the compiler to create multiple assemblies for the site, which can include one assembly per page or user control, or one or more assemblies per folder.
• You want to be able to update individual files in production by just copying new versions to the production server, or by editing the files directly on the production server.
• If you precompile the site, you want to be able to update individual ASP.NET Web pages (.aspx files) without having to recompile the entire Web site.
• You like to keep your source code on the production server because it can serve as an additional backup copy.
Azure Migration Workshop
One of the engineers on my team and I recently participated in 2-day Azure (Microsoft’s cloud) Migration workshop. We successfully deployed 2 organizational applications and a SQL database and learned a lot from the exercise. While we were there I jotted down some of the lessons learned and thought that others might find them interesting...
SQL Azure Migration
• 50GB database size limit (in relational DB format)
• Oracle databases will need to be connected to on-premise
• Need to use SQL Server authentication model
• SQL queries used by SQL Azure are slightly different from the original script...code migration wizard alters them, but the tool is still not very mature
• Cross-DB dependencies and communication is not supported...neither is distributed transactions
• SQL Server migration wizard (from Codeplex) can be used to analyze and point out DB incompatibilities before conversion to SQL Azure
• Every SQL Azure DB table must have a clustered primary key
Windows Azure Migration
• Applications need to be in .Net web application (not web site) format
• Must include Cloud project within .Net solution
• Cannot use Windows authentication model without using an AD federation-like model
• AnonymousAuthentication web.config setting is not recognized
• The WSDL of web service sites gets the port 20000 injected at the point of deployment
• Observation: deployments take a LONG time (plan on going to lunch)
• SMTP capabilities are not yet available in the Azure cloud (would have to use an on-premise solution)
• Cannot use regular file-system reading/writing
• Need of URL Mapper for Staging environment...a unique URL (GUID) is generated with each deployment
• Each web.config change, no matter how small, requires a full package redeployment
• David Pallmann's Technology Blog is a good Azure resource
• The number of "instances" in the Cloud Project configuration file reference how many VM instances are to be built
• The csfg (Cloud Service configuration file) file is the singular file (custom zipped) that gets deployed
• The word "global" cannot be used within an Azure cloud URL and Service Names/Labels are unique across the entirely cloud.
• Cannot reference anything within the machine.config file...must be moved to web.config
• At this time only 3rd-party vendors are coming to the table with VM usage monitoring tools -- this space is still very immature.
Dev Fabric
• Enables developers to build, debug, test code locally as a Cloud project before deploying to the Cloud.
• Just because .NET code runs locally using the DevFabric with a Cloud project included in the solution doesn't mean that it'll run in the cloud. Code has to be tested in both environments.
• Runs on the same OS as the local test machine. Beware: Cloud VM's are x64 slightly-tweaked W2K8 server.
• Is not a good indicator of performance…very much based on local hardware specs.
Billing & Portal
• The Azure portal makes it very unclear and difficult to determine your usage statistics for the billing month.
• BEWARE: each MSDN account holder receives 750 free hours of Azure platform which goes quickly even with only a couple of small applications and a DB deployed.
• Hours billed are for platform usage, not application usage.
Other Things to Note
• To use your own domain it is necessary to setup a DNS Cname that redirects the company URL to the Cloud URL.
• The Package configuration file (cscfg) can be changed and uploaded on the fly (# of VM instances specified in this file). Changes to the Service Definition file (csdef) however require a redeployment.
• Think of Windows Azure roles as type of VM's you'd build internally (i.e. Web Server --> Web Role, Application Server --> Worker Role, etc.).
SQL Azure Migration
• 50GB database size limit (in relational DB format)
• Oracle databases will need to be connected to on-premise
• Need to use SQL Server authentication model
• SQL queries used by SQL Azure are slightly different from the original script...code migration wizard alters them, but the tool is still not very mature
• Cross-DB dependencies and communication is not supported...neither is distributed transactions
• SQL Server migration wizard (from Codeplex) can be used to analyze and point out DB incompatibilities before conversion to SQL Azure
• Every SQL Azure DB table must have a clustered primary key
Windows Azure Migration
• Applications need to be in .Net web application (not web site) format
• Must include Cloud project within .Net solution
• Cannot use Windows authentication model without using an AD federation-like model
• AnonymousAuthentication web.config setting is not recognized
• The WSDL of web service sites gets the port 20000 injected at the point of deployment
• Observation: deployments take a LONG time (plan on going to lunch)
• SMTP capabilities are not yet available in the Azure cloud (would have to use an on-premise solution)
• Cannot use regular file-system reading/writing
• Need of URL Mapper for Staging environment...a unique URL (GUID) is generated with each deployment
• Each web.config change, no matter how small, requires a full package redeployment
• David Pallmann's Technology Blog is a good Azure resource
• The number of "instances" in the Cloud Project configuration file reference how many VM instances are to be built
• The csfg (Cloud Service configuration file) file is the singular file (custom zipped) that gets deployed
• The word "global" cannot be used within an Azure cloud URL and Service Names/Labels are unique across the entirely cloud.
• Cannot reference anything within the machine.config file...must be moved to web.config
• At this time only 3rd-party vendors are coming to the table with VM usage monitoring tools -- this space is still very immature.
Dev Fabric
• Enables developers to build, debug, test code locally as a Cloud project before deploying to the Cloud.
• Just because .NET code runs locally using the DevFabric with a Cloud project included in the solution doesn't mean that it'll run in the cloud. Code has to be tested in both environments.
• Runs on the same OS as the local test machine. Beware: Cloud VM's are x64 slightly-tweaked W2K8 server.
• Is not a good indicator of performance…very much based on local hardware specs.
Billing & Portal
• The Azure portal makes it very unclear and difficult to determine your usage statistics for the billing month.
• BEWARE: each MSDN account holder receives 750 free hours of Azure platform which goes quickly even with only a couple of small applications and a DB deployed.
• Hours billed are for platform usage, not application usage.
Other Things to Note
• To use your own domain it is necessary to setup a DNS Cname that redirects the company URL to the Cloud URL.
• The Package configuration file (cscfg) can be changed and uploaded on the fly (# of VM instances specified in this file). Changes to the Service Definition file (csdef) however require a redeployment.
• Think of Windows Azure roles as type of VM's you'd build internally (i.e. Web Server --> Web Role, Application Server --> Worker Role, etc.).
Subscribe to:
Posts (Atom)
