Having just gone through the headache of replicating my dev changes on our production servers and db, I am considering purchasing a license for Courier. Before I do, I'd like some information on using Courier with an existing setup.
I have Umbraco 7.2.1 running on my local machine, staging servers, and production servers. Will I be able to install Courier and have it pick up from there or does the package require empty environments to start of with? The dev and production DBs should be congruent in all but the content.
I am also deploying to load balanced servers with a central file system. Will this be a problem? Umbraco on an NLB has been a pain as of late so I'm rather cautious on any new packages.
As long as your environment matches the supported LBE configuration (https://our.umbraco.org/documentation/Installation/load-balancing) it should work fine with a shared file-system. The key part is that you deploy only to your authoring instance, which then updates the other servers in the LBE.
While we always say that adding courier at the beginning of a project is best, it is possible to add courier to any environment as long as you are willing to give some time to testing and configuring to work with your particular instance. The two key things here are:
1 - If you have custom property editors you may need to create custom data resolvers 2 - courier will deploy content and *all* dependencies so if you start out with a delta between dev > test > stage you'll need to make sure you are not deploying content regressions as you deploy. One way to to this is to make sure dev is exactly like live, which is exactly like test when you start. You can do a deploy live > dev of course to start, then deploy dev > test > live.
Once configured in your environment courier can take much of the complexity out of day-to-day deployments, but you do need to spend some time understanding how courier works and ensure your environments are ready for this.
Courier is an unlimited trial when used on localhost, so please feel free to evaluate.
One way to to this is to make sure dev is exactly like live, which is exactly like test when you start.
Paul, when you say "exactly like live" does that mean that the IDs must be in sync as well? The pitfall I'm trying to avoid in my case is where duplicate identically-named items get copied over and references become ambigious. I can see that happening even when reverse deploying live > dev.
A good practice would be to start by deploying everything from dev > live, where live is an empty instance to begin with. This allows courier to create a baseline graph and it's easier to determine what needs to be deployed in the future. The baseline graph is more conceptual than an actual asset, but the concept is the same.
If you have duplicate named content, it's true that courier will have a more difficult time keeping references straight. I believe in general it is considered best practice to enforce unique naming - we certainly recommend it and this is how umbraco works OOTB.
Courier on existing environments
Having just gone through the headache of replicating my dev changes on our production servers and db, I am considering purchasing a license for Courier. Before I do, I'd like some information on using Courier with an existing setup.
I have Umbraco 7.2.1 running on my local machine, staging servers, and production servers. Will I be able to install Courier and have it pick up from there or does the package require empty environments to start of with? The dev and production DBs should be congruent in all but the content.
I am also deploying to load balanced servers with a central file system. Will this be a problem? Umbraco on an NLB has been a pain as of late so I'm rather cautious on any new packages.
@Matthew
As long as your environment matches the supported LBE configuration (https://our.umbraco.org/documentation/Installation/load-balancing) it should work fine with a shared file-system. The key part is that you deploy only to your authoring instance, which then updates the other servers in the LBE.
While we always say that adding courier at the beginning of a project is best, it is possible to add courier to any environment as long as you are willing to give some time to testing and configuring to work with your particular instance. The two key things here are:
1 - If you have custom property editors you may need to create custom data resolvers
2 - courier will deploy content and *all* dependencies so if you start out with a delta between dev > test > stage you'll need to make sure you are not deploying content regressions as you deploy. One way to to this is to make sure dev is exactly like live, which is exactly like test when you start. You can do a deploy live > dev of course to start, then deploy dev > test > live.
Once configured in your environment courier can take much of the complexity out of day-to-day deployments, but you do need to spend some time understanding how courier works and ensure your environments are ready for this.
Courier is an unlimited trial when used on localhost, so please feel free to evaluate.
One way to to this is to make sure dev is exactly like live, which is exactly like test when you start.
Paul, when you say "exactly like live" does that mean that the IDs must be in sync as well? The pitfall I'm trying to avoid in my case is where duplicate identically-named items get copied over and references become ambigious. I can see that happening even when reverse deploying live > dev.
@Jason
A good practice would be to start by deploying everything from dev > live, where live is an empty instance to begin with. This allows courier to create a baseline graph and it's easier to determine what needs to be deployed in the future. The baseline graph is more conceptual than an actual asset, but the concept is the same.
If you have duplicate named content, it's true that courier will have a more difficult time keeping references straight. I believe in general it is considered best practice to enforce unique naming - we certainly recommend it and this is how umbraco works OOTB.
is working on a reply...