Release engineering: Difference between revisions

Line 1:

== 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.

== Releases ==

The workflow for ~~releasingl~~ 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.

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.

~~The 'best practices' described~~ at http://drupal.org/creating-drupal-test-sites do not adequately address the issue (it doesn't ~~even talk about using~~ version control~~, and 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).

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).

We need ~~to be sure~~ to account for ~~the~~ three aspects of the system:

In a web software system, we need to account for at least three aspects of the system:

* files (aka "assets")

* database

@@ Line 1: / Line 1: @@
+{{stub}}
 == 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.
 == Releases ==
-The workflow for releasingl 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.
+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.
-The 'best practices' described at http://drupal.org/creating-drupal-test-sites do not adequately address the issue (it doesn't even talk about using version control, and 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).
+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).
-We need to be sure to account for the three aspects of the system:
+In a web software system, we need to account for at least three aspects of the system:
 * files (aka "assets")
 * database