Good point; we can add a note to the guide to consider those when you migrate/backup a server. But, it's very easy to do; just copy whatever you have in the extensions folder (i.e. one with .bmx files), and copy them to the new server's folder. Then, restart web app and service, and it will function the same as if you had just downloaded them from Inedo.com

This could be a bug, or a configuration issue, or maybe even both... but we can definitely help you to resolve this. The Q&A may be challenging for this particular issue, so please submit a ticket so we can better work together on solving this!

This is actually a fairly common requirement with BuildMaster, and we have a lot of users who implement this in a lot of different ways. Here are the main two approaches. Different Versions for Different Customers If there is a possibility that customers will want to receive different versions of your application at different times (e.g. they may coordinate an upgrade), then the best bet is to set up an application for each customer, and then "import" the deployable from the main (customer-less, or standard) application; you can use a "controller" application of sorts to automate the build/deployment of these customer applications, or use the api. This approach will also enable "quasi-custom" software, and let you build customizations on top. All Customers, Same Version, Always If this is the case, then this is simpler on the administration side, but it can be a bit tricky on the implementation side, as there are several challenges. First, you will need to deal with the problem of adding a new customer; maybe it's not so bad, and you can do a manual copy; if you are adding several customers a day, maybe it's a problem Then, there's the problem of rollout; do you take down every customer site at once, then upgrade, then turn them on? Or do you do a more rolling strategy (one at a time), (five at a time, etc) What about failure, such as if customer 33 of 58 has an error during upgrade? Do you continue with the rest, or stop the whole process It's hard to advise on a general approach because of these considerations. There's also scope and scalability -- are you looking at a handful, dozens, or hundreds of customers? Regardless, I would look to the features in the new execution engine, as they will simplify this problem quite a bit: If you are frequently adding customers, then this is more of a "configuration management" problem, and Otter may be a good fit for the delivery aspect You can create custom "Variable functions" that will allow you to use external data sources (CRM, etc) for customer lists. then you can do something like <pre> for each $customer in @GetCustomers() { if $ShouldDeployCustomer($customer) { ... } } </pre>

Very helpful! Thanks :)

In the v4 execution engine, your best bet is to create a file with that name, and then read the file contents into a variable. In the v5 engine, you will be able to export variables via powershell a little easier (example: PowerShell & Scripting from Otter docs.

Thanks Alana, i'll check that out.

A bit late in the game for an answer, but I thought I would add my two cents: Tod is 100% correct, you do not want to use variables within Buildmaster for this, but you do not need to go the length of over-managing either. To resolve this issue: Passwords: Resolve this with the credentials for the database. Database name differences: Have your DBA create a Synonym across the board. For example, if your app is named "DirtyHarry" and on DBDEV is called "RevolverDB" and PRODDEV is called "MagnumDB" just create a synonym "DirtyHarryDB" on both servers, resolving to the actual DB name. Then in all your change scripts use DirtyHarryDB... or just set a synonym on DEV to be the same as PROD DB name or vice-versa. There are quite a few ways you can resolve issues like this, but it is always better to be genericized. We have the same in that we utilize snapshots in DEV that can be in any database location, but in production they are referenced to linked servers. -Kevin

Variable values are "cascaded" by the execution engine at runtime. So, yes; if you define it any level (server, environment, deployable, etc)., it will resolve the most specific variable definition (e.g. a "build" variable overrides a "global" variable, etc).

This can be done with Administrative Edits on the Admin > Administrative Edits > Change Release Status page

Are you referring to connecting to the BuildMaster database, or connecting to databases you have configured in the Database Connections section within BuildMaster? The former cannot be done as it must use the account that hosts the web application or service. The latter cannot be done through the web application with Integrated authentication because BuildMaster does not impersonate users like that - you must use SQL Authentication and specify the credentials in the connection string if you want to go that route. The other alternative is to create a Change Script Deployment tool, and have the respective users run the tool as their own accounts, though of course this requires manual intervention.

Yes, in the new/v5 execution engine, we wrote a variable function called $EnvironmentVariable(name) that returns the machine environment variable. The current/v4 execution engine does not provide agent/server context in a variable function, so there's no way to write a variable function that executes on a remote machine.

Great --- worth noting that, while BuildMaster most certainly has some solid build automation sever capabilities , it's primary focus is actually Application Release Automation, which has a broader scope. As such, a lot of organizations will use a dedicated continuous integration server (like Jenkins) and import/trigger builds using BuildMaster, and then securely deploy/deliver to environments.

We removed that simply because it was confusing having both actions like that, your best bet is to use the Execute Command Line action, or a PowerShell script in the script library that does what you need.

Thanks Tod! One of the downsides of moving to a beta-version of any product of course ;-). Looking forward to the next update. I'll try moving forward without the test, results are looking promising. Thanks!

Alana. I have made a pull request https://github.com/Inedo/bmx-windows/pull/30 Thanks for pointing me in that direction. It was indeed very easy to modify the codebase.

That should work; but if not, I would make sure that the instance is actually named that (that's the default name), and that the SQL Server is actually running. It's possible the service has stopped.

The size and last modified/write date are used to determine if a file changed, but in pre-4.9 versions, the local time the server creating the artifact is used in the zip file (instead of UTC), which meant the deployed timestamp could be wrong. That said, it wouldn't cause a full redeploy... only an incorrect timezone. So, let us know if you see behavior like this (or can repro it with a smaller, less important deployment). It's possible the SSH library we're using handles returning dates differently, and there's an edge case we need to address.

Status code 403 is an authentication problem; so most likely, the user or account that Git is pointing to has a password or permissions change.

The current (v4) execution engine does not support Array-type variables, so this would not be possible using that technique. But we will soon (couple weeks) be shipping v4.9, which will include a brand new execution engine, that will include Array/Vector variables, so you could do something like ... foreach $value in @MyVariableList { Transform-Config (...); }

The Click Once Action is essentially a wrapper around mage.exe; you can see exactly how this is wrapping that utility in the source code: the source code, and what those options mean at msdn. The AppCodeBase is the deployment root of your application in IIS, generally "/", but it could be "/MyApp" or something as well. If you specify "CopyFiles" in the action, then the application files and manifest will be in whatever target directory you specify. If you do not specify a source and target directory, then the default/working directory will be used for both (which means the output will be exactly where the input was -- in the $CurrentDirectory).