This is the third part in my series on the migration of fee.org to Umbraco.  This post will cover the tools and processes I used to manage this project.

Development Process Overview

Here is a high level overview of the implementation process – some of the the development steps were done in parallel:

1. Interview stakeholders – understand their workflow and goals for the new site
2. Perform in-depth site survey – build a sitemap to understand site structure
3. Document types/page field survey – survey all fields (properties) used on each page, think about how they are related
4. Template design – a combination of scraping the visual design of the old site and building static HTML for the new one
5. Document type design – implement the document types in Umbraco based on the Page Field survey results
6. Custom functionality – implement all the custom functionality not provided by Umbraco – payments, custom widgets, etc.
7. Content migration – prepare a set of migration tools which would be run at the time of the switch
8. Live release – execute the switch, including the final migration of content and media from old site to new.

Tools Overview:

• Basecamp: basecamp was used in lieu of email for information discussions.
• JIRA: JIRA is used to manage all development tasks
• BitBucket (git): contains source code & database scripts,
• TeamCity: build server used for continous integration of the dev servers and production releases
• Amazon Web Services:  hosts the application, include website, DB, email, storage, etc
• Hangouts/Skype: Permanent Hangout is used for ongoing discussion, weekly video calls on Hangout and Skype for team meetings.
• Evernote:  a project notebook contains interview notes and other various technical snippets which I might need to refer to
• LastPass: password manager which I use to store all project credentials and share them with the team

Project Tools in Detail:

JIRA Release Schedule:

A JIRA project is the first development artifact that I create.  It contains the development plan, all the individual dev tasks, time tracking, and links to git commits.  A project schedule is important to stakeholders, so I organize a high-level tasks list into pre-launch and post-launch releases:

JIRA Kanban Board

The JIRA Agile Board is how I organize my tasks.  If there is a dedicated PM who is familiar with scrum, I will use the scrum board, otherwise I will use the more flexible Kanban board.  I configured it into the standard four lanes:

JIRA Task Detail:

Pretty standard.  I link JIRA to git so the commits for each task are visible, and also to TeamCity, so that the build status for each commit is linked.  As I work on stories, I add screenshots and technical notes, for myself as much as the tester/product owner.

BitBucket

I use a modified git-flow proces – each commit is tagged with a build, releases are tagged by date, and released code is merged to master.

TeamCity

Each commit is automatically deployed to the dev site.  Live releases are triggered from TeamCity took.  I configure the Publish Web wizard in Visual Studio – this creates an msbuild configuration which I can trigger in the TeamCity build:

New Relic Monitoring

New Relic is pretty essential to running lots of websites without an ops team.  It sends alerts when there is any problem and makes it easy to identity problematic components.

 

Evernote

Everynote contains technical notes, potential third party components, and client interviews, airplane tickets, and a lot of other information I may need to refer to:

PowerPoint

Last but not least, I write regular emails and reports to communicate project status information to non-technical stakeholders and educate them about the development process.