In light of the new Fluther - What is the process of making the beta become live?

I’ll answer this after I get some sleep. Hit “Follow Question” if you want to see my answer.

We’re going to be left in the dark? ( ! )

Oh, good, he woke up.

So basically forget the beta becoming live thing, I’ll just explain the process of deploying updates to the site. From start to finish.

Each developer (Ben, Andrew, Richard, Cameron and I) runs a local copy of Fluther on their laptop. It’s like Fluther except the data is out of date and we can do anything without worrying about messing data up. Once a project is getting ready to launch we can deploy to our test server. If it’s a huge update we ask mods to take a look at it. The test server is nearly identical to production but it does differ in a few ways (mostly because it’s just one server and our production environment is a bunch of servers).

Deploying is a single command. It runs a ton of different actions. It packages up the code and puts it on all the servers. Once it’s there it changes a pointer from the previous deploy to the new one and everything seamlessly switches over. We’ve done hundreds of deploys that nobody knows about…it’s only one kind that involves even a second of downtime. Schema changes.

What does that mean? Whenever we change around or add data to the Fluther database, for consistency we have to take the database offline and perform the changes. Of course if something were to go wrong we’d need a backup, so we run one of those first. Applying the migrations that change how data is store can be quite quick. Recently though we’ve had to do data migrations. That’s where we want to store data in a new way that’s so drastic we have to grab the old data and transform it into the new schema. In this last migration we did that in more than one place (some of it was improved mod tools). One real-world example of a schema change is adding a boolean (true or false) value for whether or not a question or answer is private on your profile. We had to add that to the database.

Basically here’s the process:

1. Write your code.
2. Test out the changes on your local version of Fluther.
3. Do a code review. This involves showing all the changes you’ve made to someone else and getting feedback and making changes and fixing bugs.
4. Commit the changes you’ve made to a repository so we can roll back if we have to… (it’s actually a lot more complicated than that…)
5. Deploy to the test site.
6. If everything checks out, deploy to production if there are no schema changes. If there are schema changes then you have to pick a time to launch, publish a blog post and I usually write a script for what’s going to happen.

Big launch checklist:

1. Put the site into maintenance mode (you know the kitten picture, “we’re in your Fluther”).
2. Start the database backup.
3. Deploy the new code to the site.
4. I usually take one of the servers out of the rotation (we have a load balancer that routes your request to one of our servers at random, so pulling it out of rotation means it won’t serve traffic anymore).
5. I take that one server out of maintenance mode.
6. When the backup completes I start the migration.
7. If there’s any new software dependencies I install them at this point (could be one server or a half dozen that needs new software).
8. When the migration completes sometimes there’s some additional scripts that need to be run to clean up or post-process data (like last night I ran a script that deleted 10k duplicate topics since we have code that prevents duplicates from being made now).
9. Once I can see that one server looks good I put it in maintenance mode again and re-add it to the rotation.
10. Fluther gets brought out of maintenance mode and peace and prosperity are restored to the world.

If anything was unclear or you’d like more gory details, feel free to ask follow-up questions.

Thanks, Tim. That’s pretty interesting.

You mentioned duplicate topics—is there now a capability for approved users to become a topic cleaner-upper?

@wundayatta We are working on improving the topic editing tools and processes. We should be expanding the program shortly. We’ll probably post a blog post and the topic editing guidelines page as well. If you’d like to help we’ll let you know when and how you can sign up. Stay tuned!

@timtrueman Let me know.

@wundayatta will do!

@timtrueman You have described every day for my husband, plus checking everyone elses’ work the same way.