Web Application and Web Site Development Models
History
Visual Studio 2003 introduced the Web Application model. Visual Studio 2005 introduced the Web Site model and initially did not allow the Web Application model. Developers complained and a plug-in was released to allow Visual Studio to do Web Applications. Developer Express Supports only Web Site model originally but will add support in WDE 2008 SP1.
Web Application
A Web Application is project based. If the resource is not in your project it does not exist.
It must be deployed to be used.
Easier to work with Source Control since the projects expose source control syncronization files.
By default, all code is compiled, class files, code behind files, designer files, into a single assembly.
Content files, .ASPX and .ASCX, are compiled dynamically.
With Web Applications you have control over the names of assemblies.
Web Applications also have the ability to create a Web Application from multiple Web Projects.
Web Applications have the ability to run pre-build and post-build steps during compilation.
Web Site
A Web Site is folder based, if it is in the folder it is part of the Web Site.
Web Sites automatically deploy site using HTTP, FTP or File System.
Web Sites run on IIS, they do not run locally for HTTP and FTP.
If you specify local file system the site will run with the local development server.
A Solution file gets created but does not have any information.
Web pages and code files are compiled dynamically. (There are precompile options)
Gives you the ability to open and edit any directory as a Web Project without a project file.
Ability to generate one assembly for each page which could result in a performance gain.
Showing posts with label Brief. Show all posts
Showing posts with label Brief. Show all posts
Sunday, August 17, 2008
Sunday, May 18, 2008
UAT Environment
User Acceptance Testing, UAT for short, also goes by the name Demo or Demonstration.
If you have a somewhat typical set of environments setup to support software development, they will correspond roughly to the following:
Development (DEV)
Build
Integration (INT)
QA/Test
UAT
PreProduction
Production (PROD)
How these are used also varies slightly from one company to the next but some key concerns are addresses at each level.
Build ensures the code is in Version Control and always builds.
Integration ensures the code under development and third party code, software and legacy systems all still work together.
QA or Test validates the ever increasing feature development and bug fixes.
So it may seem like UAT is overkill. But it is precisely because the previous (lower) environments have checked out and passed on all these details that allows UAT to provide the first chance for the Customer to provide their feedback or approval. The system is in a state where it could be deployed , all of the bugs and issues have been resolved.
But it is precisely because the Customer is providing feedback here that Software Developers will be most insistent on gaining access to the system.
One reason is familiar, they need to fix something. The answer to this is the same as it was on QA, fixes should flow throught the process to keep the version integrity. (Although QA should have already found the bug so if this is a new bug, some investigation should be done to determine why QA missed it.)
Another reason is the Customer is changing their mind. Here Acceptance is called for, not only will the Customer change their wishes, they may never stop. Sometimes they flip flop between several implementations. Sometimes there is more than one customer and they cannot agree. In this case you will need to find a way to make the different options configurable. This will need to be documented in a Use Case and follow the process of every other enhancement.
But the best reason for keeping Developers off of UAT is to see "Can this solution live without the constant care and feeding by Developers?" Even better "Can mere mortal users actually use this system?"
permalink
If you have a somewhat typical set of environments setup to support software development, they will correspond roughly to the following:
Development (DEV)
Build
Integration (INT)
QA/Test
UAT
PreProduction
Production (PROD)
How these are used also varies slightly from one company to the next but some key concerns are addresses at each level.
Build ensures the code is in Version Control and always builds.
Integration ensures the code under development and third party code, software and legacy systems all still work together.
QA or Test validates the ever increasing feature development and bug fixes.
So it may seem like UAT is overkill. But it is precisely because the previous (lower) environments have checked out and passed on all these details that allows UAT to provide the first chance for the Customer to provide their feedback or approval. The system is in a state where it could be deployed , all of the bugs and issues have been resolved.
But it is precisely because the Customer is providing feedback here that Software Developers will be most insistent on gaining access to the system.
One reason is familiar, they need to fix something. The answer to this is the same as it was on QA, fixes should flow throught the process to keep the version integrity. (Although QA should have already found the bug so if this is a new bug, some investigation should be done to determine why QA missed it.)
Another reason is the Customer is changing their mind. Here Acceptance is called for, not only will the Customer change their wishes, they may never stop. Sometimes they flip flop between several implementations. Sometimes there is more than one customer and they cannot agree. In this case you will need to find a way to make the different options configurable. This will need to be documented in a Use Case and follow the process of every other enhancement.
But the best reason for keeping Developers off of UAT is to see "Can this solution live without the constant care and feeding by Developers?" Even better "Can mere mortal users actually use this system?"
permalink
Friday, May 9, 2008
Microsoft Virtualization 360
Surely 2007 was the Virtual Year.
Although Virtualization has been kicking around for some time, 2007 saw some easy to use and free versions. Add to that the time is ripe in terms of hardware. Virtualization has one OS often running on top of another. That can be quite the performance hit. The result was virtualization went from a power user or guru trick to the buzz of 2007.
So while 2007 kicked open the door in terms of price, availability, ease of use and widespread acceptance. The winter of 2007-2008 saw an ever increasing number of offerings and counter offerings. The offerings have gone beyond price and performance. Microsoft enumerates 6 uses or promises:
1. Virtual Presentation
2. Virtual Application
3. Desktop Virtualization
4. Server Virtualization
5. Virtual Storage
6. Virtual Network
Microsoft is marketing these under "Virtualization 360". Which is reassuring since so much is going on in this space, it is nice to know Microsoft is trying to gather it's offerings in one place. Judging from the presentation there is a total of 5 offerings:
1. Microsoft Virtual PC
This is listed as the Desktop Virtualization solution but it can run server OSes. Chances are good this version (and multiple copies at that) is already running in your company. The reason is simple, it is free, it is easy to use and it will run legacy OSes as well as Server OSes.
2. Windows Server 2008 with Hyper-VTM
Currently if you want to host a virtual OS directly on the machine without the host OS getting in the way you will need to use the Server Version. If you need to use 64 bit OSes you will also need the Server Version.
3. Windows Terminal Services
Terminal Services have been around for quite a while now. Microsoft wants us to think of this as Presentation Virtualization. The application will be run on one machine but the presentation of the application can be presented on many machines.
4. Microsoft Application Virtualization
This is similar to the Windows Terminal Services. Here the application is run over the network without being installed. The key here is that the configuration layer that the application uses is separated from the OS. The intent here is to reduce the conflicts created when different applications attempt to configure the platform during their install. Instead this configuration information is kept on the central location. This opens up an added advantage of centralizing the updating and patching of applications.
5. Microsoft System Center Virtual Machine Manager
And one server to store them all, and rule them all.... After working with the Virtual PC 2007 for just a few days, I had so many images of machines that I connected a 1 Terabyte external hard drive to my desktop just to store them all. While this stop gap solution gave me space for a few hundred images, keeping them organized is still quite the challenge. Plus as soon as you start working with one machine you are changing it. So you will need a way to generate new copies of your original machine. Then there is the problem of sharing the images with coworkers. We routinely have dozens of images that illustrate active problems.
So there you have it that is what Microsoft considers the complete circle of virtualization.
permalink
Although Virtualization has been kicking around for some time, 2007 saw some easy to use and free versions. Add to that the time is ripe in terms of hardware. Virtualization has one OS often running on top of another. That can be quite the performance hit. The result was virtualization went from a power user or guru trick to the buzz of 2007.
So while 2007 kicked open the door in terms of price, availability, ease of use and widespread acceptance. The winter of 2007-2008 saw an ever increasing number of offerings and counter offerings. The offerings have gone beyond price and performance. Microsoft enumerates 6 uses or promises:
1. Virtual Presentation
2. Virtual Application
3. Desktop Virtualization
4. Server Virtualization
5. Virtual Storage
6. Virtual Network
Microsoft is marketing these under "Virtualization 360". Which is reassuring since so much is going on in this space, it is nice to know Microsoft is trying to gather it's offerings in one place. Judging from the presentation there is a total of 5 offerings:
1. Microsoft Virtual PC
This is listed as the Desktop Virtualization solution but it can run server OSes. Chances are good this version (and multiple copies at that) is already running in your company. The reason is simple, it is free, it is easy to use and it will run legacy OSes as well as Server OSes.
2. Windows Server 2008 with Hyper-VTM
Currently if you want to host a virtual OS directly on the machine without the host OS getting in the way you will need to use the Server Version. If you need to use 64 bit OSes you will also need the Server Version.
3. Windows Terminal Services
Terminal Services have been around for quite a while now. Microsoft wants us to think of this as Presentation Virtualization. The application will be run on one machine but the presentation of the application can be presented on many machines.
4. Microsoft Application Virtualization
This is similar to the Windows Terminal Services. Here the application is run over the network without being installed. The key here is that the configuration layer that the application uses is separated from the OS. The intent here is to reduce the conflicts created when different applications attempt to configure the platform during their install. Instead this configuration information is kept on the central location. This opens up an added advantage of centralizing the updating and patching of applications.
5. Microsoft System Center Virtual Machine Manager
And one server to store them all, and rule them all.... After working with the Virtual PC 2007 for just a few days, I had so many images of machines that I connected a 1 Terabyte external hard drive to my desktop just to store them all. While this stop gap solution gave me space for a few hundred images, keeping them organized is still quite the challenge. Plus as soon as you start working with one machine you are changing it. So you will need a way to generate new copies of your original machine. Then there is the problem of sharing the images with coworkers. We routinely have dozens of images that illustrate active problems.
So there you have it that is what Microsoft considers the complete circle of virtualization.
permalink
Thursday, May 8, 2008
The QA Enviroment
The QA Enviroment
In Seven Development Environments:
http://andrewboland.blogspot.com/2008/05/seven-software-development-environments.html
I asserted that developers access to higher environments should be restricted. And above the QA, developers should have no access.Developers do not understand this and object. Since the objections are plentiful and compelling, a reasoned response is warranted. Both the objections and the responses vary by the environment. QA, UAT and Prod have similar but differing reasons given for developer access.Thus I will group these by environment and take on the QA ones first.
So the top three compelling reasons for access QA (Quality Assurance, also known as Test) fall into one of:
1. I need access to QA so I can install the program.
2. I need access to QA so I can fix the bugs they find.
3. I need access to QA so I can understand or diagnose the problems QA finds.
What I like about these is they are versions of "I need it to get the job done."
1. I need access to QA so I can install the program.
This is common and reveals a deeper problem or problems with the software development process.Either there is no installer or setup process for the software. Or the installer/setup is broken. Or the software requires prerequisites or extensive configuration.
Taking the last of these first, the need for prerequisites or configuration post install.The reply here is that this means the installer or the setup process is incomplete. It is fairly easy to have the installer program check for prerequisites. These days is also very easy to have the installer program include the prerequisites and install them if they are missing.Likewise, configuration post install means that there is some documentation missing. The QA team should be provided with setup instructions. If it is too complex for QA then it will be too complex for your customers.
2. I need access to QA so I can fix the bugs QA finds.
This sounds noble. And usually there is a follow on objection, "I need to fix this bug so QA can keep on testing."
But this starts a really bad habit. If the developer can change the release being tested by QA, what is it that QA is testing?
Say the version of the release that QA is testing is "1.0.23".
While that version is being tested the developers should be working on "1.0.24".
So what do we call this modified version?And then what is the QA supposed to do? Both during the time the developer is messing around in the QA environment and after?Is QA really testing that "1.0.23" release or is it now something else?
The best outcome is for the developer to spend a brief amount of time to understand the problem and then go work up a solution in the development environment.
3. I need access to QA so I can understand or diagnose the problems QA finds.
Here is where the developer needs to hold back and let QA do it's job. When QA finds a bug it should isolate the bug and provide reproduction steps.If the bug cannot be reproduced it is not a bug. Insisting on reproducible steps will help in diagnosing the problem.
permalink
In Seven Development Environments:
http://andrewboland.blogspot.com/2008/05/seven-software-development-environments.html
I asserted that developers access to higher environments should be restricted. And above the QA, developers should have no access.Developers do not understand this and object. Since the objections are plentiful and compelling, a reasoned response is warranted. Both the objections and the responses vary by the environment. QA, UAT and Prod have similar but differing reasons given for developer access.Thus I will group these by environment and take on the QA ones first.
So the top three compelling reasons for access QA (Quality Assurance, also known as Test) fall into one of:
1. I need access to QA so I can install the program.
2. I need access to QA so I can fix the bugs they find.
3. I need access to QA so I can understand or diagnose the problems QA finds.
What I like about these is they are versions of "I need it to get the job done."
1. I need access to QA so I can install the program.
This is common and reveals a deeper problem or problems with the software development process.Either there is no installer or setup process for the software. Or the installer/setup is broken. Or the software requires prerequisites or extensive configuration.
Taking the last of these first, the need for prerequisites or configuration post install.The reply here is that this means the installer or the setup process is incomplete. It is fairly easy to have the installer program check for prerequisites. These days is also very easy to have the installer program include the prerequisites and install them if they are missing.Likewise, configuration post install means that there is some documentation missing. The QA team should be provided with setup instructions. If it is too complex for QA then it will be too complex for your customers.
2. I need access to QA so I can fix the bugs QA finds.
This sounds noble. And usually there is a follow on objection, "I need to fix this bug so QA can keep on testing."
But this starts a really bad habit. If the developer can change the release being tested by QA, what is it that QA is testing?
Say the version of the release that QA is testing is "1.0.23".
While that version is being tested the developers should be working on "1.0.24".
So what do we call this modified version?And then what is the QA supposed to do? Both during the time the developer is messing around in the QA environment and after?Is QA really testing that "1.0.23" release or is it now something else?
The best outcome is for the developer to spend a brief amount of time to understand the problem and then go work up a solution in the development environment.
3. I need access to QA so I can understand or diagnose the problems QA finds.
Here is where the developer needs to hold back and let QA do it's job. When QA finds a bug it should isolate the bug and provide reproduction steps.If the bug cannot be reproduced it is not a bug. Insisting on reproducible steps will help in diagnosing the problem.
permalink
Tuesday, May 6, 2008
Seven Software Development Environments
How many environments are enough?
Well one is definitely not enough. It is usually a sign of deeper problems that developers do not insist on separate environments for development and testing. One problem could be simple ignorance. In which case a few definitions are in order. So here are a typical seven.
- Development
- Build
- Integration
- QA
- UAT
- Staging
- Production
Development: This is the wild west. Developers get to do anything here and they will. As such anything proven here is suspect. Typically the name is shortened to "Dev".
Build: Hopefully source control is in use, if it is there is a chance automated builds or integration builds will occur on a machine that is not a development machine.
Integration : As the name suggests this is were everything comes together. A typical software solution now routinely involves multiple applications under development, a few legacy applications or libraries, some third party tools and servers. And to set it all up usually requires some configuration. This is the first enviroment were application installed. Team leads worth their salt will restrict access to this environment. Perhaps read only access will be allowed to team members but the lead should insist the problems be fixed in dev. Sometimes goes by the name "Int".
QA: Another name is "Test". Developers should have no roll in this environment. If the QA team is good they will not even let development leads have access. QA testors should be able to handle the deployment to QA without the developers. If they can't then you have bugs or lack of documentation.
UAT: The longer name is "User Acceptance Testing". Here is were the client gets a chance to provide feedback. Since QA was able to install on QA, either QA or if you are lucky enough to have a Configuration Management Team will handle this transfer. Note at this point developers are no longer needed to keep the application working.
Staging: Sometimes this go by the name "Preproduction" or PreProd. This environment is handy for reducing down time and handling security issues. It is also common for the owners of the site to refuse the developers of the site any access to this environment.
Production: Shortened to "Prod" and this is the final enviroment, the real environment.
Saturday, May 3, 2008
12 Basic Software Development Practices
The gap between programming or writing code and developing software is growing.
This paradox is driven by the proliferation of easy to use tools, libraries, frameworks and OSes designed to ease the burden of software development.
Regardless of why, my experience has been that the typical software development shop is not executing on basic fundamental software development practices. A trend of late that I find even more alarming is quite often many of the programmers and managers are not even aware of or do not insist upon implementing them. It reached the point that I have enumerated 12:
12 Basic Software Development Practices
1. Source Control
2. Issue Tracking
3. Bug Tracking
4. Work Item Tracking
5. Environments
6. Integration Builds
7. Automated Builds
8. Unit Testing
9. Regression Testing
10. QA
11. Versioned Releases
12. Setups
So for a while my thinking was I can just enquire about these 12 before taking a new contract or engagement and all will be well. It is not surprising that I was always told "oh yeah we have all of that.." And it is also not surprising that expectations did not match reality. So I formulated follow on questions to determine the depth of practice.
Questions to determine depth of practice
1. Source Control
Where is the code kept?
Central location?
Individual machines?
Which version is authoritative?
2. Issue Tracking(Issues are a catch all term for everything that does not fall into the bug or work item buckets. They include but are not limited to 3rd party software issues, network issues, development machine issues.)
Is there a Central reporting tool / repository for issues?
Is there an established work flow?
3. Bug Tracking
Is there a Central reporting tool / repository for bugs?
Is there a bug workflow which includes states for:
Initial
Approved
Denied – Feature, works as designed
Denied – Not reproducible
Fixed
Verified
Reopened
Closed
4. Work Item Tracking
Is there a Central reporting tool / repository for new feature and enhancements?
Is there a work flow which includes states for:
Initial
Coded
Test
Failed
Accepted
5. Environments
Do separate environments exist for each of?
Development
Integration
Quality Assurance
User Acceptance Testing
Production
Is developer access to environments higher that Development limited?
Is developer access to environments higher than Integration denied?
Does QA or Change Management own the process of moving releases from one environment to the next?
6. Integration Builds
Does the code build from source control?
Does it build on a machine that is not a development machine?
7. Automated Builds (hourly/daily)
Is the code being built a regular basis?
Is this build done by an automated process?
8. Unit Testing
Do developers check in unit tests with their code?
9. Regression Testing
When code is built for release are all unit tests run?
Bug, Feature and QA tests?
10. QA
Is QA done by someone other than developers?
Does QA write automated or unit tests to demonstrate bugs?
Does QA write automated or unit tests to test common test cases for a feature?
Does QA write automated or unit tests for security and other required practices?
11. Versioned Releases
Is there a version number definition?
Are the products tied to the version number with each release?
Is the version number incremented with each release, both internal and external?
Does QA report bugs and test features according to version number?
12. Setups
Does each application have an install program?
If it does not have an install program are there instructions documented for manually installing the application?
After the install does the program run or is more intervention required?
Footnote. Microsoft Team System can provide them all.
permalink
This paradox is driven by the proliferation of easy to use tools, libraries, frameworks and OSes designed to ease the burden of software development.
Regardless of why, my experience has been that the typical software development shop is not executing on basic fundamental software development practices. A trend of late that I find even more alarming is quite often many of the programmers and managers are not even aware of or do not insist upon implementing them. It reached the point that I have enumerated 12:
12 Basic Software Development Practices
1. Source Control
2. Issue Tracking
3. Bug Tracking
4. Work Item Tracking
5. Environments
6. Integration Builds
7. Automated Builds
8. Unit Testing
9. Regression Testing
10. QA
11. Versioned Releases
12. Setups
So for a while my thinking was I can just enquire about these 12 before taking a new contract or engagement and all will be well. It is not surprising that I was always told "oh yeah we have all of that.." And it is also not surprising that expectations did not match reality. So I formulated follow on questions to determine the depth of practice.
Questions to determine depth of practice
1. Source Control
Where is the code kept?
Central location?
Individual machines?
Which version is authoritative?
2. Issue Tracking(Issues are a catch all term for everything that does not fall into the bug or work item buckets. They include but are not limited to 3rd party software issues, network issues, development machine issues.)
Is there a Central reporting tool / repository for issues?
Is there an established work flow?
3. Bug Tracking
Is there a Central reporting tool / repository for bugs?
Is there a bug workflow which includes states for:
Initial
Approved
Denied – Feature, works as designed
Denied – Not reproducible
Fixed
Verified
Reopened
Closed
4. Work Item Tracking
Is there a Central reporting tool / repository for new feature and enhancements?
Is there a work flow which includes states for:
Initial
Coded
Test
Failed
Accepted
5. Environments
Do separate environments exist for each of?
Development
Integration
Quality Assurance
User Acceptance Testing
Production
Is developer access to environments higher that Development limited?
Is developer access to environments higher than Integration denied?
Does QA or Change Management own the process of moving releases from one environment to the next?
6. Integration Builds
Does the code build from source control?
Does it build on a machine that is not a development machine?
7. Automated Builds (hourly/daily)
Is the code being built a regular basis?
Is this build done by an automated process?
8. Unit Testing
Do developers check in unit tests with their code?
9. Regression Testing
When code is built for release are all unit tests run?
Bug, Feature and QA tests?
10. QA
Is QA done by someone other than developers?
Does QA write automated or unit tests to demonstrate bugs?
Does QA write automated or unit tests to test common test cases for a feature?
Does QA write automated or unit tests for security and other required practices?
11. Versioned Releases
Is there a version number definition?
Are the products tied to the version number with each release?
Is the version number incremented with each release, both internal and external?
Does QA report bugs and test features according to version number?
12. Setups
Does each application have an install program?
If it does not have an install program are there instructions documented for manually installing the application?
After the install does the program run or is more intervention required?
Footnote. Microsoft Team System can provide them all.
permalink
Subscribe to:
Posts (Atom)