Difference between revisions of "Release engineering"
(New page: == General == wp:Release engineering is the discipline of releasing a software product or service to an audience. It is the liason between product managers, developers, testers, syste...) |
(only a rough draft. Expand on the ideas (with illustrations) of dependencies and requirements) |
||
| Line 1: | Line 1: | ||
| + | {{stub}} | ||
| + | |||
== General == | == General == | ||
[[wp:Release engineering]] is the discipline of releasing a software product or service to an audience. It is the liason between product managers, developers, testers, system administrators, consumers and/or users, legal, marketing, customer service and other constituents. | [[wp:Release engineering]] is the discipline of releasing a software product or service to an audience. It is the liason between product managers, developers, testers, system administrators, consumers and/or users, legal, marketing, customer service and other constituents. | ||
== Releases == | == Releases == | ||
| − | The workflow for | + | The workflow for releasing code and data from development (possibly done on a local desktop) through test, staging and on to production is both a tedious and critical process. The automation that makes this process successful is the domain of release engineering. There are many aspects to the job, as well as various degrees to which an organization will practice this discipline as a full-fledged domain. Often in larger environments where various teams are working on separate pieces of a system, you will hear the analogy of the "train" metaphor for builds moving through development and test. From the developer perspective, if your project meets certain eligibility requirements, you could get a "ticket" to board the next train which means that your feature or component will be a part of the next build, and you will benefit from that testing and availability. |
| − | + | Beware the description at http://drupal.org/creating-drupal-test-sites because it does not adequately address the issue of release engineering or testing (For example, it doesn't mention version control. The database dump and copy is overly simplistic because it assumes that you can take your site offline for the entire duration of your development cycle). | |
| − | + | In a web software system, we need to account for at least three aspects of the system: | |
* files (aka "assets") | * files (aka "assets") | ||
* database | * database | ||
Revision as of 20:19, 20 October 2008
General[edit | edit source]
wp:Release engineering is the discipline of releasing a software product or service to an audience. It is the liason between product managers, developers, testers, system administrators, consumers and/or users, legal, marketing, customer service and other constituents.
Releases[edit | edit source]
The workflow for releasing code and data from development (possibly done on a local desktop) through test, staging and on to production is both a tedious and critical process. The automation that makes this process successful is the domain of release engineering. There are many aspects to the job, as well as various degrees to which an organization will practice this discipline as a full-fledged domain. Often in larger environments where various teams are working on separate pieces of a system, you will hear the analogy of the "train" metaphor for builds moving through development and test. From the developer perspective, if your project meets certain eligibility requirements, you could get a "ticket" to board the next train which means that your feature or component will be a part of the next build, and you will benefit from that testing and availability.
Beware the description at http://drupal.org/creating-drupal-test-sites because it does not adequately address the issue of release engineering or testing (For example, it doesn't mention version control. The database dump and copy is overly simplistic because it assumes that you can take your site offline for the entire duration of your development cycle).
In a web software system, we need to account for at least three aspects of the system:
- files (aka "assets")
- database
- code
and have the release process coordinated with our version control system and testing procedures in a way that we can isolate and review the 'delta' (what is going in). Part of the install plan includes the exact steps for reversing the install. (Something failed testing, undo it.)
Basically, the process looks like this:
- develop
- test
- commit
- produce install plan (code changes and database changes)
- produce test plan (assertions to know that the changes work)
- take site offline
- install code and data
- test production
- revert or send release note
See Also[edit | edit source]
- Build Automation
- http://en.wikipedia.org/wiki/List_of_build_automation_software
- Deployment tools
- Capistrano (Ruby),
- Ant (Java),
- Maven (Java)
- Phing (PHP) http://phing.info/trac/ based on Ant, used in multiple frameworks like Zend Framework and Symfony
- Pake (PHP) http://www.pake-project.com/ "make" clone for PHP. Origin in the Symfony project, and can be used alone.
- PEAR (PHP) http://pear.php.net Don't forget that PEAR packager is a build, configuration and distribution tool. http://pear.php.net/package/PEAR http://pear.php.net/manual/en/core.ppm.php
http://morethanseven.net/2008/01/07/how-to-deploy-php-sites-with-the-pake-build-tool/
