locked
Testing, Deployment, et al RRS feed

  • Question

  • User1786833724 posted

    Product :

    Intrantet site

    Environment: 

    VS2k10/Win7, ASP.NET 4.0, telerik, LeadTools, Aspose, Entity Framework, SQL Server 2008 R2, "GrapeCity Data Dynamics Reports" (The company who makes Active Reports)

    Scenario :

    Everytime we deploy a site to new customer, we face too many issues and tangles, differant for EACH customer, the other day we had issue with JavaScripts, then finally it was figured out that their antivirus blocked JavaScript from getting dwonload. We are a small/growing company and do not have professional QAs lke many other companies.

    I need to figure this out for future releases:

    1. Is it because our test environment is poorly configured?
      • We are using VMs for simulating as near or just duplicating the configrations those of server
    2. Is it because testing is not thorough enough and that not enough parameters are being tested?
      • For example we do a large number of reports (really complex ones) and some has 25 parameters which in turn may include multi-line ones and multi-value ones, now at the minimum should we have to test the report for 25! = 1.551121e+25 values for that single report ?

    My goal here in the questions above is to figure out how history will not repeat itself, and hope that the changes occurring in our test environment and available server power will help resolving at least something, but if you've read my question patiently so far and feel like something can help me out please try to make our lives a little bit easier Embarassed

    I appreciate your time Smile

    Wednesday, April 3, 2013 9:26 PM

Answers

  • User-1916342745 posted

    Hey aarsh,

    Good question, and one that I've been fortunate enough not have to face. It looks like it should be possible though:

    http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/f21450f5-b36d-4ea2-9806-f169aff0388d/http://www.hanselman.com/blog/32bitnessAnd64bitnessAndMigratingDasBlogOnIIS7AndASPNETUnderVista64.aspx

    We use TeamCity, and Nant as a build runner (though I'd be as happy to use MSBuild as the runner). The script is something like:

    <?xml version="1.0" encoding="utf-8"?>

    <div>

    <project default="Build" xmlns="http://nant.sf.net/release/0.90/nant.xsd">
      <target name="Build" description="Compiles/Builds the Solution">
        <echo message="Building..." />
        <msbuild project="Web\Web.csproj" failonerror="true" verbose="false">
          <arg value="/p:Configuration=${config};OutputPath=${config}" />
          <arg value="/p:UseWPP_CopyWebApplication=True" />
          <arg value="/p:PipelineDependsOnBuild=False" />
          <arg value="/p:WebProjectOutputDir=..\Output\${config}\" />
          <arg value="/t:Rebuild" />
          <arg value="/nologo" />
        </msbuild>
        <echo message="Building finished..." />
      </target>
    </project>

    The section "/p:Configuration=${config}" refers to the Visual studio configuration which specifies 32/64/any configuration.

    You should just spin up an azure vm, and download team city and nant, and give it a go (or MS TeamFoundationServer). You could have it up and running by the end of the day!

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, April 17, 2013 9:53 AM

All replies

  • User-1916342745 posted

    Hi, 

    Interesting post, but you seem to be looking a two distict points:

    1. testing

    2. deployment

    You mentioned limited testing resources, but haven't gone into deployment. One thing I do note is that you are using numerous third party libraries. This is pretty standard nowdays, but you need to be careful about upgrading to the latest of each - especially with limited resources. What kind of integration testing are you actually doing? Are you using something like Selenium (http://docs.seleniumhq.org/). Automated integration testing would certainly help with some regression testing - especially when upgrading one environment. Are you using some kind of continuous integration system? If not, these are certainly worth putting is as they ensure that testing is done against a central code base, which makes running tests simple. I'm not sure how easy it would be to test for the issue that you had the other day with script blocking, though if using a CDN for scripts, you should probably have a locally stored "back" in cases where the CDN is not available. 

    I would think t hat VMs are an excellent way of doing some testing, thought you may also look at some kind of SAAS solution  (Azure, EC2), which could also be created and configured on demand - though I think a little too slowly and too expensively for yourselves.

    As far as testing is concerned, the amount you need to do is in proportion to the amount of pain you will be caused by failure. In other words, if a system failure is very expensive then do a lot of testing. 

    best of luck. 

    Thursday, April 4, 2013 11:46 AM
  • User1786833724 posted

    We are just doing manual testing, it's merely humanoid a couple people are doing this in addition to what we have to do while development.

    Thursday, April 4, 2013 3:56 PM
  • User-166373564 posted

    Hi,

    Test:

    Performance testing is used to verify that an application is able to perform under expected and peak load conditions, and that it can scale sufficiently to handle increased capacity. There are three types of performance tests that share similarities yet accomplish different goals: Load testing, stress testing, capacity testing,

    As you used many third party libraries in your application, you should check the compatibility of many third party libraries with your application, somrtimes some third party controls maybe bring protential risk,

    Deployment:

    Our configuration and deployment forum supports the deployment of asp.net application to IIS from visual studio, so I think some deployment strategies are helpful to you,

    ASP.NET Web Application Project Deployment Overview  

    In your situation, you usually need to deploy your application on local machine or a remote web server,

     In case of local machine, you can easily store it on a local drive, but if you want to deploy it on a remote server, you should have a web site, you would need a FTP/FrontPage account, IP address of web server/FTP server etc.

     You can connect remote server by FTPing web site using FTP account and publish the web site content.

    Deploy web application on remote server

    hope it helps you,

    With regards

    Wednesday, April 10, 2013 1:44 AM
  • User1786833724 posted

    @Angie xu - MSFT

    Thank you ! Yes this was certainly, a generic suggestion and I think we already are doing some of what you've mentioned. Our web site is not for public so we do "publish" from VS2k10 on our local drive and move that out-come to our company's test server ( VM ) and then some testing (depends on deadline) and then we let that package propagate onto their servers. We do this by simply copying and pasting the package from test site to production ( VPN ) and then our one small team goes to customer's office, and trains them and we're ready to support them if any issues assert which we might have missed during testing.

    Wednesday, April 10, 2013 10:51 AM
  • User-1916342745 posted

    Our web site is not for public so we do "publish" from VS2k10 on our local drive

    I think that there are several reasons for using continuous integration (continuous deployment) which I don't think you are taking into account. 

    One of the key ones is that the software is deployed from a source control system directly which means that the code has been checked in, and is part of the development history of the project.  When a developer deploys from their local desktop they can forget to push their changes to source control. Another is that you get a consistent deployment procedure, so it always works in the same way. This normally means that a deployment is a single click away. Yet another is that you are able to automate certain tests against the depolyment which means that you can have full regression testing for both unit tests and integration tests with no overhead. 

    Thursday, April 11, 2013 4:19 AM
  • User1786833724 posted

    @romage : Thank you.

    romage

    When a developer deploys from their local desktop they can forget to push their changes to source control.

    Yes this is a nice suggestion and common;y seen among many scenarios, but we're taking care of this certainly the Actual deployment goes this way :

    Dev-Version --> Testing --> Release Candidate --> Release Version --> Local Test Server --> Verifying --> Deployment --> Support

    But the tragady is,
    even after testing there are some sneaky bugs somehow manage to propagate to Deployment site FrownEmbarassed

    romage

    Yet another is that you are able to automate certain tests against the depolyment which means that you can have full regression testing for both unit tests and integration tests with no overhead.

    Undecided I am interested to get my self aware of this, can you please point me to some resources ?

    Tuesday, April 16, 2013 11:09 AM
  • User-1916342745 posted

    In terms of your depolyment... wow that must take a load of time copying the same stuff to a load of different servers. It looks like the sort of system that is crying out for automation (view tfs / team city - both of which are free for smaller options)

    Integration / regression tests ...

    http://docs.seleniumhq.org/

    http://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx

    Unit testing... 

    MSTest, NUnit, NBUnit, xUnit

    Mocking... 

    Moq etc... 

    Wednesday, April 17, 2013 6:00 AM
  • User1786833724 posted

    It looks like the sort of system that is crying out for automation (view tfs / team city - both of which are free for smaller options)

    Integration / regression tests ...

    http://docs.seleniumhq.org/

    http://msdn.microsoft.com/en-us/library/aa292128(v=vs.71).aspx

    Unit testing... 

    MSTest, NUnit, NBUnit, xUnit

    Mocking... 

    Moq etc... 

    Yeah, we heard its sobbing hence I took this initiative. The selenium is being tried by us. Just a qustion though, some of the 3rd party libraries that we're using are 64 bit as our machines are 64 but the deployment server has 32 bit architecture so we have to replace them with 32 bit ones manually. Can we also automate that ? I heard at some point that we can do some prettey good scripting or something.

    Wednesday, April 17, 2013 9:33 AM
  • User-1916342745 posted

    Hey aarsh,

    Good question, and one that I've been fortunate enough not have to face. It looks like it should be possible though:

    http://social.msdn.microsoft.com/Forums/en-US/netfx64bit/thread/f21450f5-b36d-4ea2-9806-f169aff0388d/http://www.hanselman.com/blog/32bitnessAnd64bitnessAndMigratingDasBlogOnIIS7AndASPNETUnderVista64.aspx

    We use TeamCity, and Nant as a build runner (though I'd be as happy to use MSBuild as the runner). The script is something like:

    <?xml version="1.0" encoding="utf-8"?>

    <div>

    <project default="Build" xmlns="http://nant.sf.net/release/0.90/nant.xsd">
      <target name="Build" description="Compiles/Builds the Solution">
        <echo message="Building..." />
        <msbuild project="Web\Web.csproj" failonerror="true" verbose="false">
          <arg value="/p:Configuration=${config};OutputPath=${config}" />
          <arg value="/p:UseWPP_CopyWebApplication=True" />
          <arg value="/p:PipelineDependsOnBuild=False" />
          <arg value="/p:WebProjectOutputDir=..\Output\${config}\" />
          <arg value="/t:Rebuild" />
          <arg value="/nologo" />
        </msbuild>
        <echo message="Building finished..." />
      </target>
    </project>

    The section "/p:Configuration=${config}" refers to the Visual studio configuration which specifies 32/64/any configuration.

    You should just spin up an azure vm, and download team city and nant, and give it a go (or MS TeamFoundationServer). You could have it up and running by the end of the day!

     

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, April 17, 2013 9:53 AM
  • User1786833724 posted

    Thanks romage ! I appreciate your suggesiton & porintign me some direction, yes we're using TFS 2010 and looks like what you're doing in NAnt is somethuig called build-automation in TFS terminology, I will suss that out Smile

    Wednesday, April 17, 2013 2:32 PM