Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Release Engineering in Small vs. Large

No description

Fatemeh Kia

on 25 January 2016

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Release Engineering in Small vs. Large

Release engineering
Benefits of release management
Approaches for analysis of release process
Future Work
Based on preliminary work:
Increase number of related questions
Increase number of subjects to be questioned
Developing a repository for release engineering information
Successful attempts First international workshop 2013
Second one in April 2014
Image by Tom Mooring
Large Companies
Release Engineering in Small vs. Large
Research Questions
How is a
release process
working ?
Risks and Rewards:
Fatemeh Salehian Kia, Andrej Dyck
Software Construction, RWTH Aachen University

Research Questions
Comparison by certain criteria
Future Work

What are the differences in
A problem: lack of widely-shared information:
Conducting a set of semi-structured interviews
Using articles in web logs
Large companies:
Facebook, Microsoft
Small Companies:
OEConnection, bitstars
Analysis themes:
Release strategy
Risks and rewards
Responsible release management
Tools, infrastructure
Release Strategy:
Release Strategy:
Release Strategy:
Small Companies
Release Strategy:
Risks and Rewards:
Responsible Release Engineer:
Tools, infrastructure:
It depends on the
nature of a project.
They try to keep the balance between architecture and agile manner.
Develop, test, fix errors in an agile cycle.
Release online, grow on it.
Major change is a new version.
2-3 weeks between two versions.
Risk put pressure on developers by too much features and interaction in one release.
Reward release online and get feedback immediately.
Small development team: 3-4 people
One of them is responsible for release.
There is no such a title for release engineer.
The final release push manually.
They use some tools for builds and tests.
BuildServers is used for automatically unite tests.
They use Atlassian tool: JIRA, Confluence, Dev Tool
Risks and Rewards:
Responsible Release Engineer:
Tools, infrastructure:
Defining release plan in each development cycle
Using Continuous Integration builds
Approving development by release coordinator and sending to QA team
Smoke test in production (automatically)
pushing to release
Risk no specific mechanism for avoiding
down time
fixing errors consumes time and human involvement
It has a dedicated release team
They started to automate deployment by using a specific tool which is called BuildMaster.
no automated procedure
Risks and Rewards:
Responsible Release Engineer:
Tools, infrastructure:
Minor release happens everyday.
Major release happens once a week.
Release team are responsible for deployment.
An internal tool called Relay Chat helps the workflow.
Release manager initiates a check in procedure to the developers.
Developers should submit their code.
They pay assiduous attention to the state of Facebook.
In case of errors, release team with collaboration of developer fix and release it.
Risks no-downtime
no reverting to the previous version

Controlling risk of new release by scoring developer

Rewards users' tweet helps to finds anomalies.

The release team is responsible for managing the deployment.
Specific transpiler: HipHop
Custom BitTorrent tracker
Internal Relay Chat tool
They try to automate the whole deployment process.

Responsible Release Engineer:
Tools, infrastructure:
Setting the expectations from requirement and design phase
creating project release checklist
Project team follow the release plan.
Conduction phase review issues
Deploying release to the staging environments
Smoke test
Deploying to production
Postmortem meeting (nonfunctional meeting)

Risk minimize the negative effects of new products (zero downtime)
Close work with developers
Smoke test
Parallel deployments: maintain the old version until agreement on discard.

There are six release managers for Microsoft.com.
They act as interface between operations and project teams.
They are responsible for a successful release and also release plan.
No specific tools are found.
It seems that Microsoft automatize release procedure and all six distinct phases of SDLC process.
no downtime
automation, proper testing
Early research on release management in different scale projects.
Using existing articles
Conducting semi-structured interviews

In some cases, tools and infrastructure are specific and not published.
Generic flow
when a step fails:
Go back and fix
Throw away and start from beginning
Main difference :
- Process automation
- Proper testing
No down time
Full transcript