tag:blogger.com,1999:blog-21486024094395348222024-10-24T03:26:34.995-07:00Release engineering is a discipline within a field of computer science called Software Configuration Management. For most people, this is just building and installing software. Here I will show that it can be much more.Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-2148602409439534822.post-87316461390335839432010-03-27T20:03:00.000-07:002010-03-27T20:03:13.051-07:00

Last week, I was in the middle of a failed release that needed to be rolled-back.  After rolling-back the code on the live production server, we found that there were issues.  I was not told of a release a few weeks earlier where the developer placed a single module on the server without installing an entire release. So on the next release last week, when the deploy blew away the

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com2tag:blogger.com,1999:blog-2148602409439534822.post-72706169774492099662009-08-28T06:25:00.000-07:002009-09-14T09:27:20.054-07:00

Wrote this for an branching thought:The time has comeTo branch on some,And so it willBe the head is still.Wanted to send this out to developers just before I branch for a release.

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com1tag:blogger.com,1999:blog-2148602409439534822.post-28574852317998376352009-08-19T11:12:00.000-07:002009-09-19T14:47:01.380-07:00

Working in the web app world, I frequently get asked, often by managers who aren't thinking about the product and SOX compliance, if it is OK to plop just a jsp file or a jar instead of rebuilding the entire war each time.My answer is always "No!". There are a number of reasons why, but most simply is that doing so defeats the basic tenets of release engineering: reproducability, traceability,

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-69858755110312842892009-07-13T16:11:00.001-07:002009-07-13T17:43:23.437-07:00

With agile methodologies, it is very common to have continuous integration builds. In those methodolog, there are two types of builds: successful and unsuccessful. Unsuccessful builds are builds where either the code could not compile, unit tests fail or regression tests (if part of the build system) fail. Successful builds are ones where the build completes successfully.Considering how often

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-39664112236890637152008-10-14T07:34:00.000-07:002008-10-14T08:02:38.453-07:00

I recently worked for a client with J2EE applications who had issues with my suggestions on how release engineering should be handled. So I will leave this as a lesson for those of you that might read this little blog.First, they would copy the software from one environment to the next instead of installing the software from distribution files. This led to a large number of conflicts within

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-32977447832870642992008-01-06T18:42:00.000-08:002008-01-06T15:42:47.430-08:00

I've recently created a distribution program for myself and others to use within the company. The program name is, unimaginatively, called "distrib". It reads XML data files from a server and determines the entry from the username of the application account (see previous post).Names of distribution files, server hosts and pathnames are captured in one of the aforementioned XML file. The

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com1tag:blogger.com,1999:blog-2148602409439534822.post-20167223149197543902008-01-05T19:12:00.000-08:002008-01-06T08:21:57.211-08:00

For each of the products that are installed and deployed within my company, there is an application account to go with it. The account will have a shared home directory, /home/username, and a per-host application installation directory, /apps/username.The application installation directory is managed by the product's install program. The only contents should be from the installation and from the

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-3969763744693913742007-07-06T16:54:00.000-07:002007-09-25T06:31:38.166-07:00

A QA tag is a construct that I invented over a period of time to deal with another concept called slushing. Slushing is to refreeze an intermediate "QA release". Conceptually, you freeze your code, then thaw it slightly to make a change, refreezing the code with the new change (bug fix during QA), repeat each time there is a QA iteration. At the end of QA testing, the QA tag is used to make

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-52372496608169499832007-07-02T04:10:00.000-07:002007-07-02T05:01:18.300-07:00

One issue that I have seen come up again and again in badly conceived projects is the mixing of files that should have been properly partitioned when the distributions were created. One very simple example is that log files are created in the application's root directory. This makes it more difficult for various utilities and system maintenance routines to operate as well as for upgrades within

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-47530001145912651192007-02-24T17:57:00.000-08:002007-02-24T19:36:48.418-08:00

I've finally gotten the company that I work for to standardize the release notes that are being submitted.Previously, some groups would send text files with some information, other groups would send PDF or MSWord files with other information, still more groups wouldn't send any release notes at all.The principles of the new release notes format are:easy to writetarget the audiencedocument change

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-61627779533296241872007-02-09T09:15:00.000-08:002007-02-09T09:18:28.074-08:00

One issue that has been going around my company lately is the difference between "project" and "product". This difference has affected the development cycle, project management and release engineering.Simply, a project is a work effort and a product is a deliverable. Releases are made of products, not of projects.A project could consist of multiple products over possibly multiple releases, or

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-6804715751571128392007-02-07T15:48:00.000-08:002007-07-02T08:35:26.468-07:00

As many companies have, my current employer has acquired a number of other companies and tried to integrate their technologies and employees into the fold.Of course, the release processes are completely different. At first, I did not try to merge the different processes, but developers were starting to cross "company boundaries". I decided to create a new theory of process for the developers.The

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0tag:blogger.com,1999:blog-2148602409439534822.post-52288217263064304212007-02-07T10:37:00.000-08:002007-02-07T13:24:20.863-08:00

I work at a company with a number of products. As a release engineer, part of my job is to try to standardize process as much as possible to enhance reproducibility.One part of the process that many release engineers know is sometimes tedious and intensive is the creation, testing and maintenance of installation programs. I manage over a dozen products' releases; each had their own installation

Anonymoushttp://www.blogger.com/profile/10792256458293622562noreply@blogger.com0