Sourcefabric Manuals

 English |  Español |  Français |  Italiano |  Português |  Русский |  Shqip

TagesWoche Newscoop 4.4 Implementation

 TagesWoche deployment workflow

Each deployment should be announced via email to the client. Summary of the deployment planned should contain list of tickets and information on a day and time of the update. People who should receive email are:

Thom Nagy <> and Adfinis Sygroup <>. Once deployment is done, report on deployment should be sent to the same list of people.

Deployment planning

Once a week weekly meeting of TagesWoche and Sourcefabric project managers should take a place. At the meeting, they will agree on tickets that should be prepared for the next deployment. With such a information in hand, project manager will communicate with developer in charge for deployments in order to make a final plan for the next update.

Status of each ticket in JIRA TagesWoche project should be up to date according to the workflow agreed. Therefore, both the customer and our team will be updated by checking the project in JIRA. All tickets with status "Resolved" are tickets that will go into next planned deployment. Once successfully deployed, status has to be changed into "Closed".

Use case example

Step 1: Ticket is created

JIRA status: Open

Assignee: Project Manager

A ticket is filed by the Project Manager, the client, or QA to work on a new feature, an improvement, a task or a bug. The ticket describes in detail what needs to be done by the developer, contain URL of issue addressed and appropriate screenshot(s). QA will be able to test it after looking at the description of the ticket. New features are specified in detail on a Wiki page linked in the ticket description. Report on bugs are shared from the Zendesk platform we use for TagesWoche support. These tickets has to be updated with the attachments, status and component in JIRA.

The task is estimated by the development team. Estimated hours, including all iterations and QA efforts are saved within the ticket. The ticket has to be assigned to a developer.

Step 2: Work starts

JIRA status: In Progress

Assignee: Developer

The developer starts working on the issue/story in her/his personal container.

When a developer starts working on the issue/story s/he marks it as being "In Progress". The time spent to resolve the issue/story will be logged by the developer and saved within the ticket. 

Step 3: Time to review

JIRA status: In Review

Assignee: Project Manager / QA / Client / Other developers

When the developer regards the issue/story as being done she/he changes the status to be "In Review" and assigns the ticket for a first quality review to the QA. If the QA find issues, s/he will re-assigned the ticket to the developer and as soon as she/he starts working on it, he will change the status back to "In Progress".

The review of the issue/story happens in the Development environment, the developer must provide the URL to the instance of her/his personal container where the work was performed in the ticket.

Every issue/story is reviewed in the developer's development environment and must get at least two approvals before pushing it to the next environment. Therefore, once the QA is done with the testing, he will assign the ticket to the Project Manager. Once Project Manager get the confirmation from the client that ticket is ready to go, s/he will assign the ticket to the developer in charge for the deployments with the comment that ticket is tested on the personal container and ready to be merged to the dev instance,

Step 4: In Integration

JIRA status: In Integration

Assignee: Deployment Developer

As soon as the ticket is successfully reviewed, the deployment developer merges the code to the master branch via a Pull Request, and the feature/fix will be automatically deployed to the dev instance. The developer changes the status of the ticket to "In Integration".

Developers will thoroughly review the behaviour of the system. 

If tests have been successfully executed and passed, and the development team is happy with the state of the code, the ticket will be assigned to the QA commented as "Integration accepted". The QA test it on dev instance. Once it is tested, he will update the ticket as "Accepted on the dev instance" and assigned it back to the Deployment Developer. If not accepted, the QA will assign the ticket back to the developer who worked on the task.

Step 5: Resolution

JIRA status: Resolved

Assigne: Deployment Developer/QA

As soon as the ticket is deployed to the Pre-Live environment the ticket will be marked as "Resolved" and assigned to the QA. QA will now run the final tests.

If tests have been successfully executed and passed then the ticket will be re-assigned to the Deployment Developer and commented by QA as "Tested and Accepted - Ok to go Live". The Deployment Developer will merge the version of the code, which may include not only this feature/bugfix but also all others that have been worked on in parallel, to the live branch only when preparing the actual deployment to the Live environment. The feature/bugfix will then be in production and available to end users.

Step 5: Closed

JIRA status: Closed

Assigne: QA

Once deployment is done and feature is tested on the live site, QA will change the status of ticket as "Closed" and done

There has been error in communication with Booktype server. Not sure right now where is the problem.

You should refresh this page.