0

Similar to this question Sitecore Instance Manager developer environment setup

How do you setup a new Dev environment to work against an existing Sitecore instance/DB? (e.g. onboarding a new dev)

It appears that SIM wants to always make a new SQL Server DB in addition to getting the base Sitecore files, but I don't want every developer to have their own local Dev DB... they should work against the existing Sitecore Dev instance DB.

Really it'd be great if I could just get the base Sitecore install files, on our machine, then deploy our custom code (e.g. custom ConnectionStrings.config) into that install folder, so it points to the existing Sitecore instance we want to develop against and has our code customizations.

If SIM is not the right tool, what is? How do you go about this? (I'd expect this is an easy question - think of every typical .NET MVC app you've worked on... get latest and click play...)

  • How is your dev environment setup? In order to answer this, we'll need that info. Are the databases local, or shared somewhere? What about the indexes? xConnect? – Gatogordo Jul 23 at 7:06
  • Is this SIM or SIF? 8.x or 9.x? – Chris Auer Jul 23 at 13:49
  • @ChrisAuer it's for 8.x, so SIM. I'd much prefer developers work against a common remote "dev" database (so a remote "dev" Sitecore instance), like you'd do with most typical web app projects. – Don Cheadle Jul 23 at 13:56
  • @Gatogordo - what I'm calling the "Dev Sitecore" is a Sitecore instance out on a server. I'd like to get a new developer to be able to work against that Sitecore DB with a local IIS site on their laptop (so they can easily deploy locally and test) – Don Cheadle Jul 23 at 14:38
2

SIM Tool

With your requirement for remote SQL this might not work. But with SIM you can export an existing instance and then import it again on another dev machine.

enter image description here

enter image description here

PowerShell

I have also used this PowerShell script to create Sitecore 8 instances in CI environments.

https://github.com/patrickperrone/Sitecore-PowerShell-Installer

  • So if I go this route... you're saying you basically copy the whole Sitecore inetpub folder and put it on another machine? But then how do you separate out the custom code from the rest of the inetpub files? (e.g. I believe usually you want to keep your custom source in a separate folder during development and then deploying into inetpub) – Don Cheadle Jul 26 at 0:45
  • Do the backup to a vanilla instance. – Chris Auer Jul 26 at 0:47
  • Gotcha that makes sense. So basically copying around the vanilla instance inetpub folder to stick on other machines? Interesting. A bit unrelated... but how would you go about separating custom source code from vanilla install for a site that you inherited? E.g. it's already running somewhere in inetpub with custom code bundled on top of the base instance, and no up-to-date source code repo is available for the site. – Don Cheadle Jul 26 at 0:57
  • Deploy it with visual studio or CI. If your solution or CI is perfect, you can take any vanilla machine and deploy all it needs to run. – Chris Auer Jul 26 at 0:59
  • Thanks so much Chris! But what if you inherit a Sitecore app, so all you have is the inetpub site running. Any suggestions for how you would identify the non-vanilla stuff that you'd need to put into CI or source? (since you don't just want to put the entire inetpub/asd/ site into source) – Don Cheadle Jul 26 at 17:41
1

Welcome to the site!

If the "shared" part you want is the database, the easiest way is to install Sitecore and then just update the connection strings after the installation. This will point your installation at the existing databases that you have. You can then delete your new 'empty' databases, or keep them for when you want to switch to "isolated" mode.

Just as a note, working on shared databases can lead to data collisions and file collisions. Most established teams work out a Continuous Integration strategy so that local changes can be isolated, source controlled, and then deployed to a centralized location for testing of collisions.

For example, if you use Unicorn or TDS you can sync with your local database to serialize the items you have changed and share them with the team, and similarly download from source control the changes by other team members and sync into your system.

  • 6
    Don't work on shared DBs. While it might be technically possible; just don't do it. Get those policies update for enterprise CMS development (Sitecore). – Mark Cassidy Jul 23 at 14:26
  • 2
    It's everywhere. I think the important factor here is, to get you away from the mindset that this is just "Web Development". You're about to install and run an enterprise level application with LOTS of moving parts. I'm just trying to prevent you from going down a road that absolutely will lead to hell. Shared DBs lie down that road. – Mark Cassidy Jul 23 at 15:59
  • 1
    Start here. doc.sitecore.com/developers/90/sitecore-experience-management/…. The guide doesn't even consider shared databases as an option, but proceeds to tell you about the tooling you need (TDS or Unicorn). – Mark Cassidy Jul 24 at 8:52
  • 1
    The only instance I have ever seen shared instances work is if you have a developer that is never doing any Sitecore development, and is only editing CSHTML files or JS, like a front-end developer. Then it might make sense because they can just have a local IIS site pointed at the database and get the layout working. Any 'normal' Sitecore development involves changes to the database by defining templates, content structures, security, etc. – Jason St-Cyr Jul 24 at 16:27
  • 2
    @DonCheadle if you use a shared DB, other developers will constantly break your site. Constantly. I have been doing this for a long time. Its always SQL Express and local DBs. – Chris Auer Jul 24 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.