-
Notifications
You must be signed in to change notification settings - Fork 1
-
DEF stores the configuration parameters on agent instead of packing them into the deploy package. Thus, no package has any information about the target it is about to be deployed to. If configuration changes or a new target server is created, there is no need to create a new package - just configure the target agent and redeploy the same package.
-
UI is structured around the hierarchy of Project-Application-Deploy Target. This makes it easier to manage complicated solutions ('projects') consisting of several applications (e.g., Public web, Admin web, Database, Reports, etc.) being deployed even to different computers within one environment.
-
Deploy process is carried out by PowerShell scripts and thus can be freely customized.
Well, good question but the answer is NO.
We started to work on DEF v1 back in 2012 when there was no such solution. By the time we had our prototype that confirmed the idea of using NuGet ready, first information about Octopus deploy started to emerge. We had internal debate in Baud to decide whether continue with our custom solution or wait for the commercial tool. We decided to keep going with DEF which proved itself to be a good move because we wanted several specific features in UI which are not present in Octopus deploy even today.
As DEF v1 was our in-house solution which saved us a lot of work, we wanted new features such as scheduled deployment. That's when we decided to create a second version of DEF from scratch (some decisions from DEF v1 turned out to be unnecessary such as deploy agent being also a NuGet server, etc.) And since we love open-source as well as new challenges, we want to know what is it like to maintain an open source project.