We're currently running BuildMaster and their agents under the same account. If we can turn off the "agent" role within the Server, it would help us achieve a clear segregation of concerns. We can then narrow the security the server's account runs under and since it won't be doing anything other than coordinating with agents, we can lock down the ports, etc. Ideailly, we would like to achieve the following: BuildMaster server (lightweight, has no source control providers, no dependencies installed, does NOT build anything) BuildMaster build agents (has source control providers, SDK's, etc.) BuildMaster deploy agents (on the actual target servers the apps should be executing on )

Note this response will be handled via an email chain and will require either a new SVN extension or require a change to BuildMaster to resolve. Also see the following thread on GitHub: https://github.com/Inedo/bmx-subversion/issues/9

I don't believe the "Application Modified" event is particularly useful because that simply means a field on the Application Settings page was changed (like "allow multiple active releases" was checked), and I can't think of a good reason you'd want to know when an individual setting like that changed beyond who and when since you'll notice the changes as you use the application and can refer back to the event log then. That being said, I do agree that things like deployment plans being edited should show exactly what changed... and that feature is scheduled for BuildMaster v5; check out the Road Map for more information.

You can perform any action on the BuildMaster (local) server, or on a remote (agent) server. It's quite common to use a dedicated build server (via an agent) to compile source, etc).

FYI - there is now a 30-release limit as of v4.8.2.

You don't have to install Visual Studio 2015 on the buidlserver. Install MS Build Tools 2015 will do it. https://www.microsoft.com/en-us/download/details.aspx?id=48159

This will be the simplest resolution. First, upgrade the database instance to SQL Express 2008 or 2014; this will increase your limit to 10GB. Just download and run the installer from Microsoft, and instruct it to upgrade the instance. Then, upgrade to BuildMaster 4.8, which will have retention policies that allow you to delete/purge execution logs (which are taking a lot of space).

Yes; this would ultimately be done through the typescript compiler (tsc.exe), so it really depends on how you plan to build/use them. For .NET projects, it's something that msbuild calls, and you can specify whether or not to generate the .d files in the project properties. Otherwise, you could simply call the tsc.exe directly with the desired parameters. ONce you have those, you can capture the artifact from there.

It can do that, but it won't automatically. You have to configure the deployment plans. Think of the deployment plans as a script that will run each time you deploy to an environment. For stored procedures, those should be treated as code and kept in source control, as they can be recreated simply with a DROP/CREATE/CONFIGURE script file. This way, they can be redeployed like any other artifact (i.e. extracted to some directory and executed from disk). As mentioned in the previous post, DDL/DML database changes cannot be automatically rolled back because once you DROP a column, it's gone for good until you restore from backup. Configuring a deployment plan to take a database backup is probably a good idea in this case :) You could go one step further and configure the deployment plan to restore from that backup on some condition if you really wanted to, but I would hope once the deployment is automated that these failed deployments will be kept to a minimum.

Yes; BuildMaster can do anything it is configured to do in its Deployment Plans. There's a few backup strategies you could use: zip contents of target project and move it to a backup folder deploy to a target directory then swap directory names deploy straight from a BuildMaster artifact, then a zip backup would be kept automatically (recommended) The 3rd option gives you a pretty easy way to rollback, provided there aren't API-breaking database schema changes (you'll have to restore the DB in that case, since you can't unDROP a column). See the following for more information on rollbacks: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster

Hi Steve, good question. We don't currently have a custom description per each action, but that's going to be in the v5 style plans. You can use the action group description if feasible. We do have a "show full path on hover" coming in 4.8.1 (due later today), but we can probably add in a view as well.

Yes; deployment automation is a core function of BuildMaster. The pricing is specified here, BuildMaster Licensing and Pricing, and we have service partners around the globe that can help determine cost of services (or, you can learn/use BuildMaster yourself).

Yes indeed! BuildMaster has built-in database change script and database connections for running sql scripts in various environments

For completeness, this specific issue was related to invalid credentials, in this case, the username was being entered with a domain prefix when the SVN server did not require one.

It does not, it will require a custom action or script. If you can output the current revision to a file, you can use the "Set Variable From File" action to something like $SvnRevision, then reference that later in your build/deployment plan.

Which API are you calling, the SOAP or the JSON API? And which method in the API are you trying to call? The value for the API key can be any text, and for the JSON API, would be passed in as: http://buildmaster-server/api/json/Method_Name?API_Key=yourKey&Argument_1=value1&Argument_2=value2 The easiest way to go about your issue is to create a URL-Triggered Build. Note the screenshots are a bit out of date but the information is the same.

Though the error message isn't very clear, that error means you are not authorized to view the particular server selected for the SCM provider or the action. If you have changed privileges recently, try invalidating the privilege cache on the Admin > Privileges page.

I'm not sure what you mean, are you saying all the servers on the Server Overview page are shown as "checking"? The best bet is to restart the BuildMaster service and web application if it's "stuck", but otherwise, upgrading BuildMaster should also resolve that since it no longer pulls the status directly from the DB as of v4.1

Thank you for the report - this will be resolved in v4.7.5

See: http://inedo.com/support/tutorials/performing-a-deployment-rollback-with-buildmaster