Dev server best practices?
Hello Khoros devs & techies - We just got budget approval for a dev server, yay! Curious, for those of you who have dev servers as part of your Khoros infrastructure, what are some best practices an...
Forum Discussion
For us it's essential. We like to be able to keep everything ready for very quick Stage to Production pushes so it's very rare for anything to get built in Stage which is kept as identical to production as possible.
So our workflow would normally be:
Build - Dev;
Basic Testing - Dev;
Copy - Use SDK, Studio and Community Admin (if needed) to copy Dev to Stage;
Full Testing - Stage;
Deploy - Push Stage to Production and make any required Community Admin changes.
Khoros keep both Stage and Dev up to date, version wise, for us so it's just a case of porting any structure changes backwards along with the rare things built in Stage.
This allows us to have Dev in any state we want in terms of ongoing dev work without blocking us from pushing out emergency changes like banners from Stage. Also helps in that if one developer is working on bigger changes in Dev then the other developer can make quick changes in Stage.
It also means if a large piece of work is ongoing such as re-skinning the site we are not blocked from making changes to Production via Stage.
Honestly the amount of work required to move changes back and forth to keep things in sync is minimal.
The one tip I would have is for anyone working in Dev (or Stage) to keep a .todo file listing all the changed style, component, asset and page quilt files alongside any Studio/Community Admin config changes, etc. for each piece of work. Makes moving things back and forth a lot less prone to error as does keeping a well commented Git repository for the Dev environment.
