In Visual Studio 2013 RC there is a new template in the SharePoint / Office section, the Cloud Business App. A LightSwitch SharePoint Auto Hosted Solution. With this template you can create Apps with LightSwitch for O365 SharePoint, a powerful combination.
Although LightSwitch development is that quick that it almost can be done by a single developer. But when the business requirements are getting bigger, team development with decent development, test, acceptance and production environments are a must. when this is needed, there are a few things to pay attention to, one is actually due to the nature of development in SharePoint, developers have a Developer Site for debugging. Another one is data, tables/ lists, when you make a table change, data can be removed. And one related to LightSwitch you only can create a package for a specific site.
A Cloud Business App / LightSwitch SharePoint App (O365) development and test environment.
Multiple developers work together on one LightSwitch SharePoint App.
Each developer is connected to Team Foundation Service for agile planning and source repository. Also, each developer will have his/her own SharePoint Developer Site for debugging.
Every day / every hour a ‘get latest’ is done to verify integration with the other developers.
In this way every developer will stay in sync with the rest of the team and will have it’s own environment (and test data) for debugging. Not interfering with other developer debugging actions.
Testers are connected to Team Foundation Service for test planning, test case specification and test execution. Testers have their own ‘Test’ Site n O365 with a ‘stable’ App or more important with stable ‘test data���.
(4) Triggered by testers in the team a new package is created and uploaded to the App Catalog.
When a SharePoint data source is used in the LightSwitch App the connection string needs to be changed before packaging.
Testers are now able to freely test new functionality without disruption from debugging sessions from developers. Packaging and publishing is tested too in this way. A faster way can be to give the testers in the team a developer site too, and let them test from there. They will need to have Visual Studio for publishing.
Testers validate the same functionality in the sprint as the developers realize in that sprint. So, packaging ad republishing is done very often. While SharePoint and LightSwitch are very good in upgrading the data it takes many minutes, this requests a good tradeoff when to validate new functionality.
Connected App Developers
Most often a system doesn’t live on it’s own. WinRT Apps can be connected to SharePoint 2013 Lists very easily. With this development in the team too an additional site needs to be created for them to provide a stable integration endpoint.
Developers building connected apps have a separate site which they connect to. Test data will be isolated for them so they have a stable set to test with/ debug their own apps with.
Again packaging needs to be done from within Visual Studio to set the connection string for this specific site.
Integration Testers can use the same environment or setup.
Acceptance testing is done on a separate O365 environment from a package created and uploaded to the App Catalog.
Publish – connections string
The only ‘not so comfortable’ part is that for every deployment on another site you have to set the connection string of the data source.
This is only needed when you use SharePoint Lists as a data source, and the lists must be unique for that site. A workaround for this is that you make use of the SharePoint App in the Solution and add the needed Lists to it. Then these lists will be created when you deploy the App. Drawbacks from that solution are that the data in the lists are harder for SharePoint Search and that you can’t use them as a data source in your LightSwitch solution. Which result in that you have to access the tables with CSOM because the entity model isn’t available. When done careful setting the connection string every on publish is a good enough.