43-Step Launch Checklist added to Documentation

The 100 D-Days Challenge continues, and today we're adding the most comprehensive single article ever added to UNA Docs - the Launch Checklist.

The purpose of the launch checklist is to provide a step-by-step general guide to launching a community powered by UNA CMS. There are currently 43 steps, and more will be added and cross-linked in the future. Each step offers a brief overview of what needs to be done, with more detailed articles on each step to follow in further Docs updates.

UNA is by far one of the most capable and sophisticated purpose-built platforms. It is certainly the most comprehensive community software system, but with power comes complexity. While we strive to make configuration as simple as possible, there are still many steps to consider. Often, we hear our clients ask - "So, what do I do next?" or "Hm, why is this not working?" - only to realize that an important configuration step was missed. So, this checklist is where you find out exactly what needs to be done before launch!

Read through it, even if you've already launched - chances are that it will help you review and reevaluate your setup. The first few steps cover general planning and ideation, then it moves on to installation and main config options.

If you notice any critical steps missing, or would like a detailed article on any of the steps in particular as soon as possible, please comment here. If you'd like to contribute to this or any other article - also add your content in the comments and we'll incorporate it.

  • Up vote
    18
    Down vote
  • View
    6089
  • More
Replies (14)

    • S

      Thank you Andrey and the UNA Team. Just excellent!

      • I truly appreciate your efforts in creating this documentation, Andrey. I recognize the time and patience required to complete this task, which will greatly benefit new users and bring clarity to UNA Users. I am also following the 100 days challenge you have undertaken. I admire your and your team's perseverance and commitment. On behalf of our entire community, I thank you and your team for your hard work. Take a bow!

        • Thank you! We're releasing an update next week, which brings a significant Studio makeover among other things. That has pushed back our documentation effort a bit, but once this update is out you'll see a number of module-specific tutorials.

          • Thank you UNA team for this work and effort. Much appreciated!

            • C

              This is excellent thank you for all your efforts and now this on top, Your team are the most amazing Simon

              • In one shot, they did it again. Address many of our questions and concerns, especially with the fast moving industry. We chose UNA, and we like the idea of being one step ahead.

                • I would like to impose the following, however. A standard user documentation module with the option of rebranding.

                  I managed to get a work-a-round using wiki module. But believe me if I tell you the amount of work that goes along with it, and you got to have a strong knowledge of html, integration or just general strong IT background.

                    1. however, UNA script does not have a complete documentation, only a beautiful story, but it requires a technical documentation for each UNA available version. The existing documentation is incomplete, for example for installation with docker or docker swarm, which could greatly simplify the installation. or how to install using k8, building a social network without a cluster is impossible. I didn't see any recipe for helm chart in the existing documentation

                    • @ORV Don't be so negative. UNA as it is, has the ability to take you from zero to hero. They are doing well and really try hard to make us not only happy but stay in the lead with modern days CMS products.

                      • I am not negative, I was just saying what is missing from my point of view.

                        • Point taken. thx

                          • Thank you for working on the documentation updates!

                            • Thank you very much for the checklist and all the updates have been made! 🫶

                              • I followed up the checklist. It helped me a lot, getting a clear and well thought structure🫶

                                Currentley I'm not quite sure about some configurations due to the point as you described:

                                 # Environments 
Before deployment, plan your strategy for the development, staging, and production environments. You may start with just one, initially as development, then progress to staging, or you may decide to set up and maintain all three.

Development Environment - This is a "sandbox" instance where you can experiment with different modules, settings, and custom modifications. It's for testing only, with no real users or public access.

Staging Environment - This is a "clone" of your main network, containing the same data or at least a portion of it. This environment is used to apply approved modifications or settings changes and run tests. It doesn't have public access, and notifications are turned off.

Production Environment - This is your main site, with a live database, active users, and public access.

                                All my Environments are running on the same web server.

                                Directory Structure:

                                • public_html/main
                                • public_html/beta
                                • public_html/sandbox
                                1. My Production Environment (main) is set up and installed for the first stage under main.domain (Version UNA-Spacenook-v.13.1.0)
                                2. My Staging and Sandbox Environments are set up under beta.main.domain and sandbox.main.domain but not installed.
                                • What are the configuration differences for the installation of the Staging Environmet, and how should I proceed?
                                • Using the same database and user as the Production Environment (main)
                                • Using the same database but a different user as the Production Environment (main)
                                • Using a separate database as the Production Environment
                                • I'm planning to give only users with admin rights on my Production Environment access to the Staging and Sandbox Environments.
                                • Should I use the same UNA-Key for all three Environments?

                                How can I migrate an update from my Staging Environment to Production Environment?

                                Do I need in that case a new directory for pushing updates?

                                Looking forward to any suggestions and further instructions🤩

                                Login or Join to comment.