We are investigating using CruiseControl.NET as both a Continues Integration build provider, as well as automating the first part of our deployment process.
Has anyone modified CruiseControl.NET's dashboard to add custom login and user roles (IE, Separate out access to forcing a build to only certain individuals on a per project basis?
The dashboard is a .NET App, but I believe it uses the nVelocity view engine instead of web forms, which I don't have experience with.
Can you mix nVelocity and Webforms,or do I need to spend a day learning something new =)
#Keith:
We are leveraging CC.NET to both run a CI build, as well as being able to use the Force Build feature to do a Build + Deploy. That is why we want hands off the dashboard.
I found this morning that I was able to place CCNET in a virtual directory within another web app, This allowed me to setup Forms Authentication, and let the root app manage that. Problem solved.
Why do you need to? Do you really need to limit users in the way with an integration server. I think that's why CC.Net doesn't have that sort of support built in.
You can always see who forced a build, and control it that way.
I find that continuous integration works best with regular builds and regular unit test runs (our rather large C# app + test run takes 25 mins and checks hourly), so for me forcing a build is rarely an issue.
If you want some users to have some kind of report-only access you could limit them so that they can't access the CC.Net web application at all.
All the results (MSBuild, NCover, NUnit, FxCop, etc) are in XML, so you can build relativity simple report pages out of XSLT.
Related
I am building a SharePoint 2013 provider-hosted app using the high-trust model. This allows a customer to deploy the .app to their App Catalog and make it available to all SharePoint Sites. The provider-hosted portion of the app runs in an IIS box (cluster) which the customer also deploys (on-premise) with setup instructions and automated tools.
The .app file structure includes the application manifest - which specifies the precise endpoint where the provider-hosted portion resides, and also specifies whitelisted endpoints which the add-in can call. These are all specified by entering in URLs, hostnames, and port numbers into edit fields in Visual Studio in the 'Deploy App' form just before the .app file is built and digitally signed.
This seems to work just fine for a single app built by IT folks internally, if the org is small enough... but I really want to be able to distribute this solution to more than one customer. In order to do so, I would have to ask the customer for their respective endpoints, enter them into my build tools, and rebuild the .app for them. This just doesn't seem right... no customer wants to talk to the developer first and have a custom-built app. And why should they? No code is changing...
Upon investigation into the .app file format, it turns out it is really just a simple .zip file - and inside (voila!) there is the app manifest! Unfortunately, if you edit the app manifest and re-zip the file, the digital signature is broken, and the .app no longer works. (grrrr...)
What I want to do is simply reconfigure the app manifest to match the environment where it is deployed. This can happen programmatically during setup/installation time, or perhaps even just prior to download, but cannot be a process that involves developers typing into visual studio and pressing Rebuild. That simply won't scale.
Is there a tool that exists that can help with this problem? If not, does anyone have experience with the signing of .app files programmatically? I'm open to skinning this cat in any way possible.
This is a wild idea and not maybe even possible.
Create web ui, where clients enter their endpoints.
Have internal process that invokes MSBUILD/TFS to package app with endpoint
change app manifest with pre-build powershell
Then provide app via email or download?
http://www.sharepointconfig.com/2013/10/building-sharepoint-2013-apps-with-tfs-2013/
This is more of a workaround than a true answer - but would work:
For on-premise deployments of high-trust SharePoint 2013 apps - build the application with "known endpoints" - essentially hard-coded endpoints that can be deployed locally. Then instruct the customer to redirect those endpoints using DNS records or hosts file entries. In addition, the client would need to generate a local wildcard certificate signed by their own trusted root in order to satisfy the SharePoint 2013 app model requirements for appdomain and server-to-server communication.
This is by no means ideal, but for certain environments it might be the most practical approach. This also allows scaling for the IIS WebApp to occur at the customer-site, where it realistically belongs for a high-trust app.
This approach avoids the need to automate build tools and also avoids building a separate instance for every customer - both of which are somewhat undesirable. It might, for those reasons, be slightly less costly - but it also pushes some responsibility to the customer. Namely - hard-coding a DNS entry locally for machines in the topology.
I have a solution in Visual Studio Team Services that has 2 Web Applications (specifically one project for WebAPI services and another for the actual site using MVC).
I'm trying to set up continuous delivery to Azure but all the information that I can find seems to assume that you only have a single Web Application within your solution (which seems a little unrealistic for all but the simplest of projects!).
The out of box continuous delivery process seems to just pick and deploy the first Web Application it finds (which isn't necessarily the same project each time!)
I've tried specifying the Deployment Settings file, but that seems to affect the destination rather than the project being deployed since again, it seems to just "pick" a project to deploy, and each time it deploys every single compiled assembly plus all dependencies rather than just the binaries and dependencies of the project actually being deployed, which can cause issues with MVC finding duplicate controller matches for a given name (this can of course be fixed by specifying the namespace of the controllers within the route configuration, but that seems less than ideal, and still doesn't fix the entire problem).
Ideally I'd like to find a way to deploy both projects with a single build, but as a temporary solution I'd be happy with 2 builds that are both triggered by a check-in of the single solution, that each reliably deploy 1 of the 2 Web Applications.
Does anyone know if this is possible? I guess I could write my own custom build template, but I'm hoping there is an easier answer (not least because I can't imagine that this isn't a problem being faced by other people!)
I did find this question TFSPreview.com and Azure continuous deployment for multiple solutions in TFS but since that's quite old and is specifically talking about AzureWebRoleProjects rather than Web Applications being deployed to the newer Azure Websites feature, I'm hoping that there is a more positive answer?
This is possible with multiple build configurations. In addition to Debug and Release you could specify two more, one for each app.
You can find these in Visual Studio at Build -> Configuration Manager. And then in the configurations specify only one of them to be built. Then running MSBuild with that configuration will output only one WebDeploy package.
My question is similar to this one, which remained unanswered, unfortunately.
We are rolling out a web application as a web deployment package (Web Deploy/MSdeploy) to different environments. The package is created from within Visual Studio 2012/Team Build. Several parameters are to be set at install time (connection strings, WCF endpoints, logging settings, etc.). We have these in a parameters.xml at the root of the project.
Most of our customers import the package through IIS UI. Each time we roll out an update, customer IIS administrators have to provide the parameter values again through the UI. Most of the time, parameters do not change across updates.
What is the best way to handle this? Advise customer IIS administrators to use the command-line instead, injecting a SetParameters.xml that they keep separately (the level of some of our customer administrators isn't particularly high, so having something UI-based which we can document with a couple of screenshots is an advantage)? Keep the settings file (web.config or appconfig) out of the package altogether? What is the neatest way to do this?
I had the same problem, but decided to go with the batch-script installer file that comes with the web deploy package. In my mind it is more secure, doing this installation by script, instead of having to install through GUI. It can be documented, and maybe they need to learn a little bit of command-line?
As you say, they can use the same SetParameters-file for all following releases, if nothing in it changed - which in my mind is a huge benifit - not having to manage web.configs manually.
Automated deploys minimizes manual errors.
I am working on a SharePoint 2010 Server and i have following items in my SharePoint solution
Couple of web parts
State Machine Work flow (which will be integrated to an Infopath form library)
Infopath task edit forms
Lets say this solutions is deployed to http://[SharePoint201Server]:[PortNumber-x]/
This is the only server i have (No extra server for UAT), and what ever has been done so far needs to be given for user acceptance testing (UAT). I may create one more site at http://[SharePoint201Server]:[PortNumber-y]/ for it.
My problme is that how do i maintain two copies of my source code ? I will have to continue development on the same set of source code for next UAT release. I simply can not create simple copies of the source code as it will have same Assembly name and feature id, etc..As if i do so, any changes on under Development source code would affect UAT assemblies.
One thing i can do is to create seperate projects for UAT and Development with different Features and Assembly names, but is not that too much of an unneccesory work ?
What can be the best approach in such situation ?
i would suggest use sand boxed solution and create two site collection one for UAT and other for production. deploy your solutions individually on each sandbox solution. Sandbox solutions are deployed in bin not in GAC so you would not be having trouble code duplication
There is no best approach for this. You need to have different environments for development and UAT.
If the availability of machine is limitation, One possible solution is to have VM environment of the same machine for development and actual environment for UAT.
That obviously requires sophisticated hardware configuration to run both simultaneously.
I feel like I need a better defined framework for updating my SharePoint (MOSS 2007) application with custom code changes. I am creating wsp solution files with features and new types and such, but once those get tested and deployed, I feel like it's a bit of a leap of faith, and that makes me nervous and occasionally reluctant to deploy changes. After deployment, it's difficult to correlate the current state of the SharePoint application with the specific code that is deployed on that SharePoint server. What features are actually installed and on which sites? Which features are activated or deactivated? Which version of this custom field or content type is really there? Things like this. If an error crops up, I have to rely on my assumptions about what code is there and actually running, or I have to spend time digging through deployed assemblies and the 12 hive -- not impossible, but pretty unpleasant.
What steps should I take to improve my ability to unambiguously determine the state of the application and find the code that truly represents that state? Are there third-party tools that can help with this?
I feel your pain... Application Developyment Lifecycle with SharePoint 2007 leaves me with a bitter taste in my mouth.
To answer your question. We built our own deployment utility that does a few things for us.
Checks state of key Timer Jobs (too many times we would do a deployment to find one WFE that did not get deployment)
Checks state of key Services on all our web front ends (again we want to know health of farm before we start kicking off timer jobs).
Shows file version and date of selected assemblies from GAC (does this across all Web Front Ends). We have seen problems before where assemblies did not get installed correctly across the farms.
Updates web.config settings based on an custom XML scheme we provide. We ran into some problems with web.config updates so we have thought about creating a utility to validate the web.config (specifically make sure there are no duplicate entries for specific keys).
Push content type updates (first time content types are deployed via feature it works great, but as soon as you need to update that content type it gets tough).
Checks status of WSP package after deployment or upgrade.
This utility uses the SharePoint API to do most of this work. Some of it is done by checking WMI Events.
Unfortunately the SharePoint development experience is lacking in this regard. As long as you are "namespacing" all features deployed using solution packages, you can use solution management from central admin to keep track of versions, and what gets deployed to which site collection.
Features are scoped from all levels from the farm to an individual web; so maintenence from that level is a little tough. I just try to organize all deployed code from the (top down) solution level.
It gets even more complicated when deploying custom timer jobs, event handlers, etc; I really hope that version next will address a lot of these common developer concerns.
Isn't the only way that you have a planned/controlled deployment process and a version management system like TFS
In the current project I am involved in we have:
Continuous builds
Daily Builds on a development server
When we release something to test we merge the code to the Main bransch in the version management system (TFS)
When tested and ready for production then we merge the main bransch to the release bransch
Using this structured way we always knows what is deployed in what environment and can also track all changes based on environment or changes in requirements(are also tracked in TFS)