Dev server best practices?

I’ll preface this - We have one, we stopped using it after a month. Our engineer just didn’t see the point in it anymore as it became such a headache to maintain multiple instances especially when using custom attributes as we are. With multiple engineers or larger projects involving third parties it can be super helpful, though  

I believe you can request Khoros to keep it updated with the latest releases not that it probably matters much anymore with Classic and limited updates. I think it’s a bit up to the engineer how best they wanna maintain code between them, our engineer found it best to just copy/paste when ready to move things to stage I believe. 

Keeping everything synced is hard, and why we ultimately failed to use it. As soon as it’s not perfectly aligned it’s hard to get it back, and asking Khoros to mirror Stage to dev is a pain, let alone ensuring dev is then mirrored to stage.

The only time I found a dev instance in addition to a stage instance useful was for a major rework like a complete redesign and/ or restructuring part of a relaunch where you touch everything. This usually means dev of a few months where you still need to perform maintenance and content/asset updates on your production community via the stage instance.

Other than that I only ever used a dev instance as a playground to break stuff, but for the exact reasons Stan described it was to cumbersome to incorporate into a multi-instance development workflow.

Curious to learn why you asked to get one in the first place, CarolineS ? 

I'll echo the sentiments of StanGromer and Claudius . We however took it to an even larger level in our previous contract. We currently have 4 classic environments: Dev, Test, Stage and Production. We did this as we were doing a merger of two communities and wanted minimal disruption of stage and prod during the 6 month migration and redesign project. Here is how we worked through them.

• Development: only developers on this instance. They would do all their main work here including their Q&A and then copy/paste the changes into the test environment
• Test: The community team and others we assigned would test all the changes here and document any issues. The developers would then update and test the dev environment and pass fixes to the test environment for us to check again.
• Stage: once we gave final sign off on the test environment, all changes were copied and pasted into staging. We would then do shorted testing round to make sure everything appeared fine before pushing to production that same day if possible. 
• Production: One more spot check after the push to ensure nothing went wrong

For the project it was ok but I'd say the Test environment was overkill. Keeping them all in sync has been a major issue as we and the devs often explore setting changes and issues on an environment and forget to revert. When we updated the community to Hermes this year we used only three of the environments and honestly, we are dropping back to stage/prod upon our renewal later this month. As we are planning the Aurora move next year it didn't make sense to pay for the extra environments. 

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.

Thank you all so much for your insights!! We are doing a big redesign right now (yep, on classic... figuring our move to Aurora will be a good while down the road), and having just staging & prod has been interfering w/ normal operations. So we anticipate using the server just for a few months while we are actively working on this big project. It's a lot of $ for just a few months, but also we need to be able to do our normal stuff while doing the redesign. That being said, I'll review with our dev partners (Glowing Blue) if it's really going to be worth the headache (which headache is bigger, ha!)

FWIW, after further discussion / reviewing this FANTASTIC and super insightful thread, we decided the dev server is still worth it for this case of doing a big redesign. We do wish Khoros had a 6-month dev server option but I imagine the overhead of setting it up makes minimum-12-month policy necessary.