Welcome to the Inedo Forums! Check out the Forums Guide for help getting started.
If you are experiencing any issues with the forum software, please visit the Contact Form on our website and let us know!
migrating from Octopus Deploy
-
Our Octopus Deploy environment is multi-customer, multi-environment continuous deployment to several different on-premise windows servers.
We are interested in using Inedo Buildmaster as a drop in replacement for Octopus Deploy.
Currently we use Envirornments in Octopus Deploy for Test, Staging and Production.
Test and Staging deploy to the same on prem windows servers. The production deploys to the production windows on-prem servers.We also use Tenants and they are organised by customer, project and environment.
The projects are the artifacts (software deployed) to the tenants and environments that belong to the project.So in a nutshell we are deploying several .Net Framework solutions to several customers on several on-prem windows server from Azure DevOps pipelines (test, staging and production).
Is this possible in Inedo BuildMaster and what would be a similar setup or maybe I can word it better.
Is there a one to one mapping of Octopus Deploy Projects to Inedo BuildMaster and what are Projects called in BuildMaster.
The same question again for what are Octopus Deploy Tenants called in BuildMaster and lastly what are Environments in BuildMaster.If this has been asked before or there is a description of this on the Inedo BuildMaster website than I would be thankful for where I can find it. Otherwise I would also be thankful for a short description or answer to my inquiry about how BuildMaster maps to Octopus Deploy as a Deployment tool for Azure DevOps.
-
This post is deleted!
-
@uel_2013 (I deleted my previous reply since I learned a few more details from a team member who talked with you already)
Given your team size, you'd definitely be better off upgrading (rethinking) your CI/CD processes when switching over to BuildMaster. As some users have told us, the Octopus Deploy way is like "trying to apply the SVN mindset in a Git world".
The main benefit to a small team is that it's a simplification/consolidation of build- and deployment tools, while also giving you a powerful platform and process. We're working on "codifying" this in an upcoming guide called Lean Platforms: Engineering & Orchestration.
You could likely get BuildMaster to work in a similar way (i.e. a "deployment script runner"), but you'll be "fighting against the current" and you would be missing out nearly all of the benefits. For example, we have different ways of handling multi-tenancy (e.g. depending on if you do quasi-custom software) and the Git and Issue-tracking integration will make a huge difference in your internal processes.
I'd suggest taking a quick tutorial of the software (you can freely download it), and see how far you can get with setting a basic application from scratch. That should help you see the differences and how the concepts maps. There are a lot of similar ideas, but like Git and SVN, there are differences that don't translate very well.
-- Dean
