TagesWoche Newscoop 4.4 Implementation
development staging environment
In this section you will learn about the development work-flow to be followed when implementing a customer project.
The following image shows how the work is performed in each development environment, the actors and their roles in each environment, and how the software gets built and deployed.
And here the narrative to explain better what happens:
- The developer writes the code in her/his personal development environment
- ... once the code gets written, and the task is tested and accepted, the developer submits it to the Integration environment by opening a Pull Request, where the code is then merged
- ... as other members of the development team report bugs back to the developer
- ... more changes are made and submitted
- ... which get merged into Integration.
- A thoroughly review happens in Integration and once the developers are happy with the state and behaviour of this version of the code
- ... it is tagged in Git and the Lead Developer promotes this new version of the code to the Pre-Live environment
- ... at this point the QA team starts a new iteration of testing
- ... issues found are reported back to the developer
- ... who fixes them
- ... by again opening a Pull Request to Integration, which gets merged
- ... when all bugs are fixed a new version is promoted to Pre-Live
- ... and this process is repeated until the QA team declares the version in Pre-Live as "Ok to go live"
- ... the Lead Developer prepares the new deployment
- ... and the new version gets released to the Live environment.
- 17. 18... A new development cycle starts, which is a repetition of steps 1 through 15
Now let's see what happens at the level of the issue or user story in JIRA.
User story / Issue Lifetime
Step 1: Task is created
JIRA status: Open
Assignee: Project Manager / Lead Developer
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. 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.
The task is estimated by the development team. Estimated hours, including all iterations and QA efforts are saved within the ticket. The ticket may stay unassigned within the Backlog or put into a Sprint and assigned to a developer.
Step 2: Work starts
JIRA status: In Progress
Assignee: Developer
The developer starts working on the issue/story. Any new feature/bugfix is developed in a separate branch within the developer's fork. This branch should be named as follows:
- For a new feature: feature/<jira-ticket-id>-<short-descriptive-title> (e.g. feature/wacsi-1234-new-section-layout.)
- For a bug fix: bugfix/<jira-ticket-id>-<short-descriptive-title> (e.g. bugfix/wacsi-1235-collapsed-elements.)
When a developer starts working on the issue/story she/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.
Co-working on a issue/story can be done by having a co-developer forking the feature branch from the main developer for this task. Co-developers contribute by running pull requests to the main developer's fork. All changes will be collected in the feature branch of the main developer.
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 usability review to the Project Manager, for a first quality review to the QA team, and for technical review to other developers. If the reviewers find issues or want to have enhancements, the ticket will be re-assigned 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 in her/his personal container where the work was performed (e.g. http://feature-motm-905-frontpage-sidebar-blog-teaser.zentralplus.maja.sourcefabric.net.)
General Policies
- 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: one from the QA team, the other one from either a code reviewer or the Project Manager/Customer. The Definition of Done must always be followed.
- Partial implementations must never be promoted to the Integration environment.
Step 4: In Integration
JIRA status: In Integration
Assignee: Developer
As soon as the ticket is successfully reviewed, the main developer merges the code to the integration branch via a Pull Request, and the feature/fix will be automatically deployed to the Integration environment. The developer changes the status of the ticket to "In Integration".
The instance running in the Integration environment is accessible via http://<project name>-dev.lab.sourcefabric.org.
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 Lead Developer and commented as "Integration accepted". The Lead Developer runs a Pull Request to the pre-live branch, and the feature/bugfix is then deployed to the Pre-Live environment.
Step 5: Resolution
JIRA status: Resolved
Assigne: QA / Lead Developer
As soon as the ticket is deployed to the Pre-Live environment, the ticket will be marked as "Resolved" and assigned to the QA team. QA will now run both manual and automated smoke tests as well as specific tests to check if the feature/bugfix is working as described in the ticket.
The instance running in the Pre-Live environment is accessible via http://<project name>-prelive.lab.sourcefabric.org.
If tests have been successfully executed and passed then the ticket will be re-assigned to the Lead Developer and commented by QA as "Tested and Accepted - Ok to go Live". The Lead 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.
The ticket is checked as "Closed".
Code flow
