AgileApps Support Wiki

User:Aeric/Old Release Process

From AgileApps Support Wiki

This is the new, vastly improved, totally streamlined release process. For your amusement and edification here is the OLD Release Process.

Requirements

  • New versions of the logo files, if not already present:
    • skins/lj7monobook/LJ_Logo.png - Logo image at top left
    • skins/lj7monobook/longjump.ico -- favicon file (image used for links)
      See Rename the Wiki for tips on editing these files.

Link-Processing Overview

Assume that the version of the Wiki that is about to be promoted is "80", and that the version about to be retired is "72". The goal, after doing the release, is to have links working like this: 

CURR PLATFORM (LJ)             APACHE             WIKI
=============                  ======             ====
   Help: {host}/wiki ---+---> (dispatch) ---+     lj70
                        |                   |     lj71 
                        |                   |     lj72 <-------+
                        |   NEXT PLATFORM   +---> lj80 <---+   |
                        |      (QAMAIN)           lj81     |   |
BookMarks               |    =============          ^      |   |
=========               |   Help: {host}/lj81 ------+      |   |
   Page at {host}/wiki -+                           |      |   |
   Page at {host}/lj81 -----------------------------+      |   |
   Page at {host}/lj80 ------------------------------------+   |
   Page at {host}/lj72 ----------------------------------------+

In essence, the release process is as simple as configuring Apache to dispatch "/wiki" links to the new directory.

In practice, several additional steps are needed to configure the affected Wiki's, so they work properly. All are equally minor:

  • In the now-current version:
    1. Tell MediaWiki to generate "/wiki" links for cross-references
    2. In LocalSettings.php:
      • Tell search robots that they can index these pages. (Uncomment $wgNamespaceRobotPolicies)
      • In the HD and LJ skins, turn on google analytics.
  • In the "retired" version:
    1. Tell MediaWiki to generate "/ljNN" links (e.g. /lj72)
    2. In LocalSettings.php:
      • Tell search robots not to index these pages. (Comment out $wgNamespaceRobotPolicies)
      • In the HD and LJ skins, turn off google analytics.

Goals achieved by this process

  • Google always finds /wiki pages as the most frequently accessed, and most recently updated.
  • Google analytics are always turned on for the current (/wiki) pages, not prior or future versions.
  • All links sent to customers by support go to /wiki pages
  • Those links continue to work when new versions of the wiki are released--but they go to the most recent version of those pages
  • Pre-release links to /lj{future_version} wiki pages work when that version becomes the current wiki
  • Those links still work when that version is no longer current

Prepare for the Release

  1. Generate a new version of the javadocs and push to the server
  2. Get the latest Eclipse Plugin (Dmitri) and push to the server

To release a new version

Thumbsup.gif

Tip: Before you start, go here to make a copy of these instructions and fill in actual version numbers.

Setup: On Local System

In /{retiredWiki}

  1. Edit LocalSettings.php:
    • $wgScriptPath = "/{retiredWiki}"
    • $wgArticlePath = "/{retiredWiki}/$1"
    • Comment out this line to enable search robots on article pages:
    $wgNamespaceRobotPolicies = array( NS_MAIN => 'index,follow' );
    ==>
    #$wgNamespaceRobotPolicies = array( NS_MAIN => 'index,follow' );
    • Comment out Google analytics in rally360 skin. (Leave its variables alone.)

In /{newWiki}

  1. Edit LocalSettings.php:
    • $wgScriptPath = "/{newWiki}"
    • $wgArticlePath = "/{newWiki}/$1"
    • Uncomment this line to disable search robots on article pages:
    #$wgNamespaceRobotPolicies = array( NS_MAIN => 'index,follow' );
    ==>
    $wgNamespaceRobotPolicies = array( NS_MAIN => 'index,follow' );
    • Uncomment Google analytics in rally360 skin. (Leave its variables alone.)

In /apache_config:

  1. Edit mediawiki.conf_new
  2. Change the "wiki" alias to point to the new release:
    Alias /wiki /user/share/mediawiki/{newWiki}

Setup: On the Server

  1. Start VPN
  2. Login as root using PuTTY or SSHshell

Deploy

Do these steps as close to simultaneously as possible:

In FileZilla, apache_config

  1. Get the current configuration file, just in case someone else modified it
    ./get_conf
  2. Save the current settings:
    cp mediawiki.conf mediawiki.conf_sav
  3. Upload mediawiki.conf_new
  4. In FileZilla
    • Upload {newWiki}/LocalSettings.php
    • Upload {retiredWiki}/LocalSettings.php
  5. In PuTTY or the SSH shell, load the new settings:
    • pushd /usr/share/mediawiki/apache_conf
    • ./try
    The script does a restart. Ignore the error that says
    "Could not reliably determine the server's fully qualified domain name".

Finally, Test the Wiki

Test

When done

  • Tell Uday to change the main Wiki link in ISV version of the platform from /lj{old_version} to /lj{new_version}.
(He needs to change a database entry--unless they're pointing to /wiki.)
  • Keep your cell phone with you at all times over the weekend
Upgrades tend to happen on a Friday afternoon. Wiki problems are rare, but they do occur. Keep your cell phone with you, in case you need to be reached.

Useful Linux Commands

  1. Copy uploaded mediawiki.conf file
    • cd /etc/httpd/conf.d
    • \cp -f /usr/share/mediawiki/mediawiki.conf .
    (cp is aliased to safe-copy. \cp unaliases it. -f forces the overwrite)
  2. Change owner of the file from root to ftpuser. (Sometimes needed when copying mediawiki.conf that was created or edited by root, to allow overwriting in FTP.)
    • chown ftpuser:ftpgroup mediawiki.conf

EVEN OLDER PROCESS

This was the nature of the historical insanity that preceded our move to a server that gave us the ability to configure Apache.

Process Overview

Assume that the current version of the Wiki is "71" and that the version to be promoted is "72". The process works like this: 

 Before             After  
========          ======= 
  lj70              N/C       No change
        
  lj71 --(rename)-> tmp       Step 1: Folder Rename
   :                                  Rename the lj71 "redirect folder" (points to /wiki)
   : (redirect)
   v      
  wiki --(RENAME)-> lj71      Step 2: Wiki Rename (folder rename + file fixes)
                                      Rename the current /wiki folder to it's actual version 
                                               
  lj72 --(RENAME)-> wiki      Step 3: Wiki Rename
                     ^                Rename the ".next" wiki folder to /wiki
          (redirect) :
                     :
  tmp  --(rename)-> lj72      Step 4: Folder Rename (so "current version" points to /wiki)

  wiki ---(copy)--> lj73      Step 5: Create Branch (the ".next" wiki folder)

Goals achieved by this process

  • Google always finds /wiki pages as the most frequently accessed, and most recently updated.
  • Google analytics are always turned on for the current (/wiki) pages, not prior or future versions.
  • All links sent to customers by support go to /wiki pages
  • Those links continue to work when new versions of the wiki are released--but they go to the most recent version of those pages
  • Pre-release links to /lj{future_version} wiki pages work when that version becomes the current wiki
  • They still work when that version is no longer current

Requirements

  • New versions of the logo files, if not already present:
    • longjump_version_logo.gif - Logo image at top left
    • longjump.ico -- favicon file (image used for links)
      See #Rename the Wiki for tips on editing these files.

To release a new version

Thumbsup.gif

Tip: Before you start, make a copy of these instructions and edit them to fill in actual version numbers.

On local system
  1. Rename: /lj{old_version} --> redirect_tmp
    Ex: /lj71 --> redirect_tmp
    • This is a redirect folder.
    • It's only contents are index.php (the php redirect file shown below)
  2. Rename: /wiki --> /lj{old_version}
    Ex: /wiki --> lj71
  3. In /lj{old_version}/LocalSettings.php:
    • Modify $wgScriptPath
    • Comment out Google analytics
  4. Rename: /lj{new_version} --> /wiki
    Ex: /lj72 --> wiki
  5. In /wiki/LocalSettings.php:
    • Modify $wgScriptPath
    • Set the "product version" variable that defines the backup file name.
      $pv = "lj80";
    • Enable Google analytics
  6. Rename redirect_tmp --> /lj{new_version}
    • This step redirects all /lj{new_version} bookmarks and email links to the current wiki.
On remote server
  1. Rename: /lj{old_version} --> redirect_tmp
    Ex: /lj71 --> redirect_tmp
  2. Rename: /wiki --> /lj{old_version}
    Ex: /wiki --> lj71
  3. Upload /LocalSettings.php
  4. Rename: /lj{new_version} --> /wiki
    Ex: /lj72 --> wiki
  5. Upload /LocalSettings.php
  6. Rename redirect_tmp --> /lj{new_version}
  7. Test:
    • The new version
    • The redirect
    • The old version
  8. Verify:
    • Nothing exists in the redirect folder, other than the redirect file, index.php, and the symlink to the download/ folder.
      (Otherwise, people with version# links to the downloads & javadocs will keep going to the old versions.)

Notepad.png

Note: When we're hosting MediaWiki ourselves, we can put the redirect into Apache, and it will apply to both the download/ dir and the wiki. In the meantime, since we don't have access to the Apache server at Siteground, the best we can do is set up index.php so it redirects Wiki links, and make sure that download/ links simply break until links or bookmarks are updated.

When done

Tell Nirav/Uday to change the main Wiki link in platform from /LJnn to /wiki:

  1. Change the database entry
  2. Export the patch to the developers
Reason: When help links go to /LJnn (e.g. /LJ80), Google indexes /LJ80
with every hit. But we want to Google to be indexing the most recent version (/wiki), at all times.
Retrieved from "https://agileappscloud.info/aawiki-src/index.php?title=User:Aeric/Old_Release_Process&oldid=13628"