As for the architecture, BuildMaster consists of four main deployable components: Web Application - the primary interface to BuildMaster Service - running aside the web application, the BuildMaster Service is a Windows Service that performs tasks requested through the Web Application Database - a SQL Server database which stores the state and history (you can use your own if you have one) Agent - a light-weight application installed on servers in which BuildMaster can manage and orchestrate Hope that helps.

Yes, as long as BuildMaster supports (see http://inedo.com/buildmaster/integration) the source control provider. It is a best-practice to label your code with a release and build number combination such that it can be retrieved at any point in the future, and more specifically, if you are promoting your code to a further environment. You can set up your BuildMaster action to use the built-in variables %RELNO% and %BLDNO% to accomplish this.

Sure, while you don't have to, BuildMaster is designed to schedule automatic deployments to, for example, an Integration environment immediately upon source control check-in. These plans can run tests, automatically deploy, etc. See our Continuous Integration section on our features page (http://inedo.com/buildmaster/features/continuous-integration) if you would like more information on how BuildMaster works as a CI tool.

BuildMaster is not a build tool in the same sense as make, Rake, Ant, NAnt, etc. However, BuildMaster will integrate with an ever-growing list (http://inedo.com/buildmaster/integration) of build tools to manage your build throughout its release lifecycle by providing an automated deployment mechanism that enhances repeatability, auditing, and maintainability.

First and foremost, it's not a "competing" process, but more of a complimentary one. That is, BuildMaster can be used to automate a RoR deployment via the RAKE action. If you're using db:migrate, this is handled via the RAKE action in the exact same manner. If you'd like to try more advanced database development (as RoR's database support does not use features such as triggers or foreign key constraints), then BuildMaster's change script feature is available for you to try. The primary benefits to doing this are the added dimensions/concepts of applications, releases, builds, promotions, etc. - instead of just files and (possibly) changesets. For small, part-time hobby projects, these benefits are akin to the benefits added by source control and/or issue tracking - just about beneficial enough to use, but not enough to pay for (thus why we have the free edition.)

BuildMaster is licensed to named users who can be managed at any time within the software itself. In our Enterprise Edition we also offer User Classes, which permit only the necessary functions in the BuildMaster software for certain users. For example, your workflow process may require that managers sign-off on a build before it is promoted to the Production environment. The only operation the manager will ever perform in BuildMaster is that approval; therefore, you may purchase an "Approval Only" license at significantly reduced cost for this user.

In addition to what Karl said, as of BuildMaster v3.1 we have made agents extensible. As an example, we now offer an SSH-based agent that uses the SFTP protocol to communicate with a remote server, instead of the traditional SOAP channel. This means that nothing needs to be installed on the remote server, and because agents are extensible, you or we could develop, for example, a Powershell or FTP-based agent.

BuildMaster locks agents to avoid corrupting them during updates by creating a file named "locked" in the same directory as the remote agent service executable (bmagent.exe) or under the \bin directory for the IIS hosted agent. In rare cases this "locked" file will not be removed when an update is complete. If the Server Overview page shows that the agent is available and updated to the newest version of BuildMaster's core and extensions, feel free to simply delete the "locked" file.

The most likely reason is that you have recently installed something that requires a restart (usually a Windows update). That installation won't actually be finished until the system has been restarted. It is also possible that something was installed very recently and the Windows Installer service has not terminated yet. It should release locks and automatically terminate after a few minutes.

Normally you only need to activate if you have a new license key or if the hardware on the BuildMaster server has changed significantly (a different CPU and/or primary network card), and there is a 7-day grace period after setting a new key before activation is required. Basically, you just need to activate after setting a new license key - and there is no harm in activating multiple times.

There may be a number of reasons why a builds aren't being created: Verify that there are releases for the target applications; a build cannot be created unless a release exists. Make sure the build schedule (under each app) is there, and not set to "disabled." Verify that the service is running. (Admin -> Service) Look for entries in the error log (Admin -> Errors) to see if anything popped up overnight. Verify that the ScheduleExecuterThrottle (Admin -> Advanced Settings) is a positive integer (default is 1).

When you say delete, do you mean remove from a workflow such that the build never travels into that environment? If so, just delete the workflow step from the workflow. If you actually want to keep the workflow step but remove all the action groups, just delete them one-by-one.

I was refering to Strong-Naming. I was using a passworded file .pfx and therefore causing issues, I moved to a .snk file (not password protected) and it's working correctly now.

That error message says "DirectoryProvider 1" which is the built-in provider. If you open up the Admin Tool located in the BuildMaster installation directory you can switch the directory provider to the LDAP one.

The password being displayed is by design, since the same privilege (Builds_ManageBuildSchedules) is required to both view and edit the build schedules, therefore showing it on one page is essentially the same as showing it on the other. You can disallow users to view the schedule details by denying the Builds_ManageBuildSchedules privilege to whomever you do not want to view the passwords.

The "Execute Database Scripts" action executes all the scripts in the specified source directory (and all subdirectories of that directory) on every execution. The only scripts that are run once and only once are the Change Scripts via the "Execute Database Change Scripts" action. Can you verify that: the action is referencing the correct provider and instance the action is running the correct server if applicable, previous actions are putting the .sql files in the correct source path on the correct server the source directory of the "Execute Database Scripts" action has the files you expect in it

Awesome! It looks like the API is working without a hitch in powershell. At this point, we probably have enough to to start with and a few angles to test. If we have any issues with the API or procs, we'll come back here. Thank you!

This can sometimes happen when the cookies are not cleared properly after an upgrade. Try flushing your browser cache and clearing your browser's cookies, then visit the BuildMaster site root, e.g. http://buildmasterinstall.corp/

Wow, that was quick! Thanks!

Thanks but I've had to revert back to 2.6.3 for now after spending most of the day trying to get the update to work. Will try again with 3.1 when it's available.