Build and Release Engineering

Interview Questions for Build & Release Engineer

2012-01-07T02:03:00.000-08:00

If you are preparing for an interview as Build & Release engineer position, you are reading the right blog.

During my 6 years of B&R experience, I have learnt that tools used for CM, Build management and scripting vary a lot in different corporations. You might be using InstallShield for deployment in one company and a simple MSBuild script in another. As a build & Release engineer you must master at least one scripting language- Perl, MSBuild or Shell. That is really helpful even if you are not currently working on any of these.

Regarding interview questions, I can think of following-

How do your handle upgrade scenario in InstallShield wizard? How can you prevent a product being downgraded while installation.
Can you write a custom action in VB/C# and integrate it with Installshield wizard?
How do you implement Continuous Integration using CruiseControl?
What are the things you change on your target system while deploying?
How can we migrate from one CM tool to another, say SVN to TFS?
Which one is a better Build Management tool- CruiseControl or Hudson? Why?

Please feel free to drop me a mail regarding any of these questions. Good Luck.

Standard build process using Make & Ant- Part 1

2009-12-26T10:33:00.000-08:00

(Mostly, I interact with makefiles but I have always been interested in studying Make & Ant together. Here is the first post in the series)

A simple build can be started from a command line simply by executing 2 statements- one for compiling and another one for linking. But as the software grows and consist of many modules, dependencies get created and a sequence of commands are required to be executed. Additionally, we needed to add pre and post actions around the calls to the compilers such as a check-out from version control or copying of deployable objects to a test location.

Make & Ant make it happen in a standardized way. Ant does the same thing for Java environment what make does for C++. Ant is a platform-independent (like Java) scripting tool that lets you construct your build scripts using many built-in commends like delete, jar, get, mkdir, exec and copydir.

Another basic difference between Ant and Make is that Ant uses XML (build.xml) to describe the build process and its dependencies, whereas Make has its Makefile format.

Best approach to prepare install patch for an enterprise application

2009-09-25T00:32:00.000-07:00

I will start with something I have worked on, then people can share their approaches. I worked in InstallShield PackageForWeb (A light weight version of InstallShield) to install patch of an enterprise application over a cluster of windows machines. I believe using an InstallShield product for installing is much easier and controllable then any other language like C#. Regarding the complex install script, I don't think we need to play with the script. Latest InstallShield provides pretty much user-friendly configurable mechanism which automatically generates the install script.

If your enterprise is too complex to be handled by general InstallShield settings and you feel the need to modify the install script but worried to mess it up. You can try this- Launch a separate script written in any Windows Automation Languages (AutoIT or Auto Hotkey) during installation and let that script handle the rest. This approach is pretty useful because these windows automation scripting languages can do anything with windows we can think of, I mean anything. I have successfully tried this approach for over 2 years. Suggestions are welcome .

Why working for Cisco is so great?

2009-08-23T22:28:00.000-07:00

Sometime I wander why am I so satisfied with my job of build and release engineer, it is quite an offbeat career. I think it has very much to do with the fact that I am working on a Cisco project. Everything around me is Cisco, Cisco's network, Cisco's processes, Cisco's people and Cisco's world class working environment. Here I am listing down some of the points in this reference.

VPN is wonderful- It feels so satisfying reading your mails on your office laptop using VPN even if you are on vacations siting 2500 KM from office. It gives me the feeling that I am not missing any update.
Responsible reporting- Weekly Update meetings with Cisco managers give feeling of responsibility. Apart from cultivating professional attitude, it feels good while interacting with so important and influential people around the globe.
Cisco's resources- Knowledge-rich resources enables you to work with more confidence. Ranging from online technical resources to industry updates mailer, everything is so perfect that it feels working in a truly world class organizations.
Wonderful people- Fortunately I have some of the best skilled engineers and most professional managers to work with. Learning from an old-timer expert and reporting to such great managers equips me with professional aptitude.
World class infrastructure of Infosys- It adds moon to the night when I hit the beautiful pool side gym in the evening after hard day's work. I feel proud walking in the rain sometimes on wide beautiful roads laid in the green campus of Infosys.

All these things coupled with other numerous untold facts add enthusiasm to life and my work here in Infosys for Cisco.

Release Management: Central Function or Dispersed?

2009-02-27T21:27:00.000-08:00

Mr. Andrew, Build and Release Manager at Marks and Spencer asked a question about the release management on my LinkedIn professional group. I think this is the question on the mind of many release managers. Following is his question and my subsequent answer. There were some other beautifully crafted answers to the question but here I am presenting only my answer.

Andrew's Question: Hi, I'm trying to understand what is the best practice for Release Management in a very large organization. Currently I have a central team of about 25 Release Managers that manage releases throughout the entire lifecycle (into System Test, System Integration Test, User Acceptance Test, Operational Acceptance Test and Production).

However, I'm not sure if this is the best model for the business. My development colleagues have suggested that releases into System Test (not int. test) may be better controlled via the Development Teams, thus increasing release turn-a-round (less red tape!), although this brings concerns of control, environment access, etc, etc, into my mind.

I'd like to canvass ideas and thoughts around this please. Many thanks in advance of your support, Andrew

My Answer: There is no single model that fits for all but I don't think releases into system test can be controlled via development team in an efficient way. In fact such a move can divert the development team from their core function along.

Assuming release manager as a single point of contact in your organization, transferring such work to development team could bring a situation of uncertainty amongst people requiring a release. Depending on the size of organization, there will be a number of people looking for the right point of contact for their release requirement/advice along with the nightmare of tracing the culprit if anything goes wrong.

Assuming the ultimate responsibility of Build Release Engineer

2008-12-21T00:14:00.000-08:00

Recently I read a book "Responsibility at work" by Howard Gardner from the Infosys central library. It was a thought provoking collection of research articles from various scholars working on various aspects of responsibility, ethics, dos and donts at workplace.
One article which I liked the most was concentrating on "Taking Ultimate responsibility". When a reader reads an article, he relates it to himself and that's what I did. I don't remember the exact article but I will summarize the content and how it is related to my work.

When I reach office, I generally have 9-10 tasks at my end waiting for my actions, these may be mails awaiting my response, regular builds awaited to be monitored, regular merge notification response queries from various teams. As per the article, it is my ultimate responsibility to address them without even considering the level of effort and recognition.

First thing should be to priorities them and note down at daily planner and if possible assign deadlines to them. Being a build and release engineer, I should go one step ahead of my defined role of releasing the builds, it should include maintaining consistent bug deadline monitoring and resolving inter-team defects conflicts. That's how we take "Ultimate Responsibility".

Build/Release Engineers will turn into Build/Release Consultants

2008-11-08T04:09:00.000-08:00

As more and more software companies are adopting Agile development methodologies, the focus is shifting to Automated builds which require less manual intervention. Although Automated builds need less effort, they need a better initial planning and a solid release strategy.
So my point is here that future software industry will see more Release Consultant then Release Engineer. This way software companies will be further improving their productivity by automating their release management activities, anyway with the help of Release Consultants.
There is a free webinar from Electric Cloud, the build automation experts here.

What is the future of Build and Release Engineer? Part-2

2008-11-05T01:08:00.000-08:00

To continue from my part 1, next answer is given by Stephan Schwab. He is International Software Technology and Agile Development Consultant. Thanks much for such a realistic views on Build/Release Engineering. I personally don't agree with Stephen's views but as a free blogger, it is my responsibilities to present facts as it is.

He says- I'm creating software since 1981 and have never felt any need for a dedicated build/release engineer. Regardless of the language used.

Don't confuse build/release with deployment/operations. For the latter you certainly want to have a dedicated team to fulfill these functions.

In agile development you should have an automated build that never - under no circumstances - takes more than 10 minutes to finish and doesn't depend on any infrastructure. So "building" is just a matter of checking out the code from the repository on a virgin machine and then you start the build. If you have to setup the environment, install a database or whatever else, then you are asking for trouble. Don't do this.

I've seen build/release engineers at clients who were just acting as a roadblock to developers. These guys usually make things complicated just to protect their job. That's not in the interest of the development team neither of the company they work for.

A good build is simple, requires no maintenance and everybody on the team is responsible to execute it multiple times a day to run all the tests before submitting new code. And developers should not sit on code either but integrate frequently and early.

Build and Release Definitions

2008-09-19T07:50:00.000-07:00

These are the basic definitions every Build and Release Engineer should be aware of. Build and Release, these two terms are so related to each other that sometime they are used interchangeably. To minimize the confusion, I compiled these definitions.

Build and Build Management- The process of converting source code artifacts into some desired product executable file. Historically, this is thought of as "compiling," but it also includes things like linking, packaging. The control of the "source of the source", the build environment, build scripts and build schedules. The person who "manages" the build environment and controls execution of builds is called a Build Manager, even though they rarely have any management responsibilities. While in larger organizations there may well be a Manager of the Build Team, this is not what is meant by the term Build Manager. Think of Build Management as being in control of the kitchen, the equipment within it and the available ingredients, as well as cooking pies. In this analogy, a Build Manager is the head chef.

Release and Release Management- A release is the consolidation of all deliverable elements, whether resulting from a build, generated artifacts from another process or acquired from third parties, into a controlled staging area. It is generally organized into the same package(s) so that it can be deployed to customers or end users. A good release is the one which contains all the deliverables, control information and release notes in one package so the end customer need not to worry much about deployment. One can think of a release as a shrink-wrapped package full of "good stuff." Continuing the analogy, a release is a pie in a box with the appropriate labels affixed. The control of the selection of release components, the release environment and the tool-chain required to produce a release. Note that the description is very similar to that of Build Management. That is because these two activities are closely related. Release Management is analogous to a production line where many pies are produced, boxed, labeled and placed in a storage facility awaiting purchase or shipment.

Build management is the definition, support, and enforcement of processes for preparing software executables from source code (deployment) whereas Release Management is the same thing from deployment to production. Summarily Build is a process whereas Release is an artifacts.

Tool Spolight: Cruise

2008-09-05T05:41:00.000-07:00

Recently there was a discussion on this new tool for Release Management called Cruise on this Journal.

Release management is often that part of the software development life cycle which has the entire team chewing its nails. Use Cruise, the Continuous Integration and Release Management system from ThoughtWorks, to remove the suspense and unpleasant surprises associated with software deployment.

Model your release work flow and ensure a hassle-free software deployment with revolutionary Pipelines. Get control of your release process by managing it through Cruise. Save time by parallelizing your tests and testing on multiple platforms. Release software quickly and repeatably with new and tested features.

Cruise draws from the extensive continuous integration experience of ThoughtWorks, the creators of the original CruiseControl.

Well, I am yet to figure out the difference between Cruise and CuiseControl.

What is the future of Build and Release Engineer? Part-1

2008-08-01T04:36:00.000-07:00

Since the time, I have taken the responsibility of Build and Release Engineer in my organization, this is the question spiked up in my mind.
I was, in fact I am very much curious to know the answer. So I asked this questions to many people in the industry through a professional business network contacts. I received the answers to my email but for benefit of other people in the same kind of job, I will be posting those experts' views here.

I am starting with the answer of Mr. Phil Davidson, Senior Program Manager at Microsoft. I am very much obliged to him for his time to write me this.

He says- I believe it is an area that will still require people and focus, however, I believe that the mindset and activities will transform. With the current pace and change to be "agile", it becomes more important that there is a process that can allow the developers to keep focused on building products and features instead of needing to worry about setting build systems and servers.
The world of Build will need to start focusing on providing a service to the development teams and in that provide the necessary systems and support to ensure that the dev teams can deliver high quality code.
By ensuring the proper quality gates are incorporated as a part of the build or post build process ensures that once the code is checked in, you know it is in as good if not better state than it was prior to the check in.

I believe that part of the responsibility will be in the area of consulting where they can provide the dev teams with recommendations and guidance. The build service team can help them to be able to know the best ways to utilize the service and system to get the biggest bang for their buck. The release team will be able to help them in regards to deploying or shipping the highest quality products and services through making sure the right processes, procedures, and quality gates are in place or get setup.

Another area is in the area of tools. Tools that will automate and facilitate and ensure that devs can be running at as fast a speed as possible without reducing the quality nor the stability of the product/services they provide. This is really about ensuring the ability to scale up and scale out as we watch the speed of software development as well as the size and number of products continue to grow.

I believe there is a need going forward, it is up to the build and release people to make sure that it adapts to the changes being seen and adopted by the development teams around the world. The skills of how to build and ship/deploy a product in the best way to optimize the build and release experiences.

Build and Release Engineering

2008-07-30T23:05:00.000-07:00

Build and Release Engineering, a term which has been synonymous with my name in my team where I am involved in Building, Wrapping and Releasing patches and fixes for various releases of the Cisco software.
I am starting this blog to sharpen my knowledge and spread the awareness about this very important but often neglected aspect of software engineering.

Declaration: I also declare that any information given here will be general in nature and will not expose any Cisco specific processes and technologies.