SSWUGtv: Budgets, Chargebacks, and ROI — oh my!
With Stephen Wynkoop
How to you calculate the value your organization brings to your company? Nobody likes to have additional overhead taken out of their budget unless they think they are receiving the best value for their investment. Can you demonstrate the valuse your IT overhead brings to your company?
Watch the Show
More on the Release Process
Today we are going to review at a high level some techniques for using version control to help manage the movement of releasable software. This is especially importantant if you have multiple efforts sharing the same code base.
Veroncia Writes:
i’m very interested in this topic since i’m trying to implement database objects releases in a team of about 40 developers. We use Team Foundation source control and my major challlenge is the "leap frog" releases, meaning shared code in 2 different versions.
example: version 1 in alpha testing and version 2 in beta testing.
Veronica’s question is one that demonstrates the need to be able to maintain code at multiple stages of a release. So, what repositories do you need in your version control? How do you manage change in different stages of a product release? I have experienced a few different methods.
1) A single version of the truth. In this method, all code is maintained and modified in the production branch. This is a very dangerous methodology for software that is anything but maintenance mode only. I was amazed when I heard of a major software vendor making production changes and applying them to the next nights compile cycle for a bug we discovered on their behalf. The developer simply made a code change and checked it in. Hope he got it right.
2) A single branch of truth. In this scenario a single branch of code is maintained in version control. Save Points are created for particular versions. As the version moves through different stages of release from Dev, QA, Prod any modifications made are not merged back directly into the head of the version control tree. Changes are made twice. One change is done externally in bits retrieved from the Version Save Point, and then duplicated into the head of the version control.
3) Sunny demonstrated a few days ago, in his question about continuous integration tools, what I have seen as a more common Version Control approach. A separate branch is maintained for all stages of the release. Sunny has a Dev, QA and Prod branch in his version control. New changes are performed in the Dev branch. Those changes are then merged to QA once approved in the development environment. Having completed QA approval and Release acceptance, the changes are again merged from QA into production.
In this scenario, should modifications be required in QA or prod, they can be expedited by making the change in either the Prod or QA branch, and then back merged to the lower level repositories
4) A more recent methodology I have experienced is to maintain a central version of truth sometimes called the Trunk. This technique is a better fit when a shared repository is used for multiple efforts that may have different release cycles.
No developing is performed in trunk. All development is done by branching off trunk as needed. When the work is completed it is merged back into Trunk. Other branches may then get the modifications from trunk as needed. If they don’t, then their changes are merged back into the central trunk when they have completed.
A continuous build may be established for trunk and/or any branch off trunk. As I have studied the process used for building Microsoft Windows it follows this model rather closely.
In order the last two processes to be effective, the team requires professionals with experience of merging code in a version control system. Some version control software does a better job at merging than others. Mercurial is especially good at merging. I guess this is because it uses local repositories such that sharing code with more than one developer is generally the result of a merge process.
There must be many other techniques for managing your version control source tree. I have found these last two techniques to be very effective integrating with a continuous build process. That is because you can have the event of source being committed to version control be a trigger to start, or prepare to start, a build and test process. We’ll talk more about that later.
You may note that I have not committed to a specific version control tool. The reason is that most modern Version Control tools support the key features required for any of these models as well as integration with continuous build tools.
Because I lean toward Merge Based release methods I am going to want a tool that is the most effective merging data.
Join the conversation by sending your comments to btaylor@sswug.org.
Cheers,
Ben
$$SWYNK$$
Featured Article(s)
Joining Relational Data and XML Data In a SQL Query
In this article, you’ll look at how you might merge external XML data into an Oracle database and then join that XML data with relational data stored inside the database within a single SQL query.
Featured White Paper(s)
How to Use SQL Server’s Extended Events and Notifications to Proactively Resolve Performance Issues
read more)
Featured Script
dba3_MedicalDB_Schema_Article
Legislated mandates are driving more implementations of row level security schemes . The article describes a generic DBMS bas… (read more)