Closed (fixed)
Project:
User Guide
Component:
User Guide content
Priority:
Normal
Category:
Task
Assigned:
Reporter:
Created:
28 Jul 2015 at 20:38 UTC
Updated:
16 Sep 2015 at 17:34 UTC
Jump to comment: Most recent, Most recent file
Title: Concept: Development Sites
Section: Installation
File name: install-dev-sites.txt
Covers: Talk about why you'd want to have one or more development or test versions of the site, to test new features before they get pushed to "live". Using revision control for the files.
Attribution
See https://userguide-drupal.redesign.devdrupal.org/guidelines/guidelines.ht...
Written by https://www.drupal.org/u/diana.lakatos[Diána Lakatos].
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | install-dev-making.txt | 2.16 KB | diana.lakatos |
| #2 | install-dev-making.txt | 1.9 KB | diana.lakatos |
Comments
Comment #1
diana.lakatos commentedComment #2
diana.lakatos commentedA first pass at this concept topic.
I tried to avoid Git specific language (branches, merging), but I thought repository can still be understood without knowledge of Git. Please let me know if I should edit it!
Also, I added an index entry for "Deployment Workflow", because I thought someone might be looking for it that way.
Please let me know what you think! Thank you!
Comment #3
jhodgdonLooks great! I really like especially the first paragraph/sentence, where you define what a development site is and what it's used for. And I agree about the index entries. We might also want one for "staging site"?
So, a few thoughts/questions:
a) Do you think the workflow would be formatted better if presented in a definition/labeled list instead of a bullet list?
http://www.methods.co.nz/asciidoc/userguide.html#_labeled_lists
b) I'm wondering if this topic should also talk about strategies for content. For instance, you would normally want to have some live (or similar to live) content available on the local/dev/staging sites, and in some cases, you might want to stage content (although I think most people would stage content via workflow all on the live site, rather than putting it on the staging site). So... not sure?
Ah, I guess we have the planning-workflow topic (which you wrote), so maybe we can reference that as far as planning your live content workflow (in Related Topics perhaps?), but I think we should also say something about wanting to have the dev/staging sites have live content on them so that you can test how the new code will work with the existing content.
c) In my experience as a site builder, it's often not just code that I've written that I would want to test on the dev/staging site before I put it on Live. I also would want to test things like:
- New modules being added/enabled
- Changes to views or panels or other config
- Theme changes (CSS, which not everyone thinks of as "code")
So maybe these should be mentioned explicitly?
Thoughts? These are more suggestions than requirements... what do you think?
Also I see in your Attribution you didn't put Pronovix in this time... did you mean to omit it because this was on your own time, or was that a mistake?
Comment #4
diana.lakatos commentedThank you for your detailed review!
Adding staging site to the index is a good idea, I added it.
a) Well, I was thinking about this while writing the list, as we've changed a bullet list of definitions into a labeled list in a previous topic. I wanted to convey somehow that these are chronological steps, I even thought about having a numbered list, but that seemed too much like a series of steps, so this is how I ended up using the bullet list. I think that the bullet list conveys that the items are part of the same workflow better than the definition list, because in that I see each item as independent. A bullet list is unordered by definition though, so this is more of a feeling than a fact. :) Also, if we want to "reserve" the bullet list for the links in the Related topics, etc., sections, I'm happy to change it to a labeled list.
If we agree on something about the list formats, it would be great to add it to the guidelines so that they will be used consistently throughout the guide.
b) Yes, I think it will be helpful if we mention adding live content as well. So I added a sentence about that and linked to the editorial workflow topic.
c) I think although of course it's not only the code that you need to test, going into too much detail in this topic might distract readers from focusing on the concept of the development workflow. If we mention themes, modules, views, panels, etc., we would need to add them all as prerequisite knowledge, and I'm not sure if that would help site builders starting out with Drupal. This is why I often referred to the newly developed part as features, although it's true that I used "code" a couple of times as well. I rephrased the copy a bit, so that it doesn't contain "code" anymore, and also mentions other parts of site building, albeit not explicitly. Please let me know what you think!
I'm working on this topic on my own time, this is why I changed the attributions information.
I'm looking forward to your thoughts and review of the updated topic. Thank you!
Comment #5
jhodgdonOK, I'm convinced, and I think the updates look good. Adding this to the guide source. I'll get it up to the site shortly.
Thanks for all the writing -- really appreciated!