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. That's why we have the free community edition.
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 of build tools to manage your build throughout its release lifecycle by providing an automated deployment mechanism that enhances repeatability, auditing, and maintainability.
Similar to the previous question, BuildMaster is not a build tool, but can be used to schedule automatic deployments to, for example, an Integration environment immediately upon source control check-in. See our Continuous Integration section of our features if you would like more information on how BuildMaster works as a Continuous Integration tool.
Yes, as long as BuildMaster supports 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.
As for the architecture, BuildMaster consists of four main deployable components:
Agents and servers are generally synonymous - an agent is a lightweight service that BuildMaster sends requests to in order to run actions on a remote server. Environments are on a "higher level" than servers; they describe a stage of testing that your application is currently in, e.g. "Integration", "QA Testing", or "Production". Server groups are a way to simplify deployment to clusters, if necessary. Environments can consist of any number of servers and server groups.
You can still work with other servers without an agent, but you're limited to whatever you can do in a normal Windows environment. For example, you can transfer files over UNC paths so long as permissions are set-up, etc. installing an agent and hooking it up to BuildMaster (via External Servers) allows a higher degree of control.
Agent Requirements: Windows Server 2003 or later with at least .NET 2.0 installed for the IIS version, .NET 3.5 installed for the self-hosted agent server, or Linux with Mono and Apache (or other Mono-compatible web server).
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.
This message is coming up when the website renders. If I close out and try to go to other pages too, it is not rendering the page and the same message comes up.
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.
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.
There may be a number of reasons why a builds aren't being created:
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.
If your server has FTP access, BuildMaster includes a set of FTP actions that allows you to send files to, get files from, or delete files from an FTP server.
It is also worth noting that it is possible to deploy to a UNC path without adding additional servers if you want and are able to go that route.
As for the build servers, if you intend to run any actions remotely on those servers you must have an agent on them since that involves running executables. The workaround is to host your BuildMaster instance on your build server, then you wouldn't need to run actions remotely.
