Since the number of certified partners is growing and more and more consultants are being educated by their certified colleagues, I thought it might be good to have a clear understanding of how you manage your sets, environments to come to a succesful, maintainable deployment.
As we all know, configurations are created in the development modus of the environment. Always try to make sure you have a good representation of your customer environment. It’s not mandatory to have a copy of the customer environment, but it is recommended, especially if you build links into your environment that specify a certain document or something.
Before you start building your configuration make sure that you have a good design and clear picture of what you want to achieve with your configuration. Thinking about your solution in advance saves you from a lot of trouble in a later stage. This mainly applies to what you build your indexes for your tables from. Remember, you can’t change the field type of your unique fields after you have generated the entity.
Tip: it’s always wise to develop against the latest version of the release your customer is on and to update your customer within the release upon live deployment.
So, now that you’re all done with the configuration it’s ready for testing. For this purpose you make a test deployment that you install on a different environment and the user or customer can start testing.
Only when you have reached agreement with the user that this test set is ok, you create a customer deployment set.
This is also the moment where you make your backups, so that you can always fall back on the situation that was agreed upon. Now, what should your backup contain?
– First of all the deployment set.
– Also good practise is that you have a copy of the database.
Of course each partner can save their set where ever they want, my recommendation would be to link it to the account card in your synergy environment so that you have a good overview.
Only after having installed the customer with the agreed configuration and have the customer work with it for a while, I would start adding to the configuration or make changes to the configuration. A lot of times I see that people are phasing this, but the moment of deploying on a live environment, it’s recommended that you freeze development.
On a regular basis I see consultants having issues because they are not building on the correct environments or are already buidling new features. Quite frequently the customer wants to have small additions to the current configuration and also has a larger plan in scope.
If you have already continued with the future plan on your configuration environment, you will not be able to facilitate these small findings or be able to deploy them fast because you no longer have that original environment.
Another consequence is rebuilding configurations with a future scope simply because the customer wanted to have additions to his first configuration.
If these environments are not managed correctly, you can find yourself stuck between a configuration and a customers wishes.
Hope this helps you a little in managing your customer environments.
Should you have any questions about this solution, do not hesitate to contact me at firstname.lastname@example.org or add comments to this post.