Automatic or Nightly Builds? When, Why, and Why Not

I've had two different development teams over the past couple of months try to convince me that implementing either nightly or automatic software builds is critical. Now I've been a part of many software development teams and none of them employed any of these builds. This includes a shrink wrap software package company that had a half dozen products built from a very large common code base and delivered for PC, Mac, and UNIX. It also includes an ASP (Application Service Provider, or now known as SaaS) that had a base web platform and application that was customized to hundreds of websites.

Even in my last post, Top 10 Tips On Version Control for Small Agile Software Teams, I received a number of comments regarding nightly builds. I did some poking around on the subject and found this relatively old, but good entry on Joel Spolsky's blog Daily Builds Are Your Friend.

So here are some examples where a nightly or automatic build makes sense:

  • Your team is implementing unit tests. Unit tests can run as part of the nightly build and alert developers on errors.
  • Developer instances may not have access to full data sets or production data. New tests can be built and automated for the nightly build to test and report on changes to the code (features) against a more complete data set.
  • You have a QA member on the team that will perform functional and regression tests on the nightly builds.
  • You want your stakeholders to review and comment on checked in features.
  • You have other teams that perform other tests and validation. Maybe load testing, browser testing, or builds for multiple OS's.
  • Your building a SOA set of shared services and want to run tests against older versions.
  • You have multiple features being developed for a single release and may need to role back to a stable point if implementing one feature is dragging the time line. Let's call this lazy branching.
These are all good examples, but I still maintain that they're not necessarily the first thing a new development team should prioritize. Implement your nightly or automatic build when you find a customer (QA, stakeholder), a process (unit testing, load testing) or to address an issue.
continue reading "Automatic or Nightly Builds? When, Why, and Why Not"

Top 10 Tips On Version Control for Small Agile Software Teams

Version control is a fundamental software management tool and process. If you're looking to setup a development environment for a startup, I highly recommend getting version control in place as a step 0. Even startups that have very few developers (even one!) will find long term benefits in having version control configured before development begins. In more established development teams, converting to version control can be more challenging because it often requires changes to existing development, build, and deployment processes. But if you keep things simple, then configuring and migrating even the largest teams is achievable in short time frames.

My simple tips:

1. Insure that your build process is applied to a working set of code. In other words, don't force developers to check in code prior to doing builds. Doing will likely cause developers to check in buggy code and cause issues with other developers.

2. You still want developers to check in code frequently. This is a management process, not a version control issue. If the tasks assigned to developers can be completed in a short duration, say two days max, then you can force developers to check in code when a task is complete. Scripts can be used to monitor the Repository for developers that have not checked in a defined period of time.

3. Backup your repository. Daily if not even more frequently.

4. Develop a simple nomenclature on what information should go into the comments/properties of a code checking. Best case - if you're working with SW requirements w/ ID's, then check in code with the IDs of the requirements (or bugs) that are being addressed.

5. Ask developers to do minor code reviews whenever they update their sandbox. See Simple Code Reviews Using Eclipse.

6. Tag your releases. If your staging a release, say through a QA process, then you can tag the release with a convention that includes the status (QA, PROD, etc.) and a version number for the release.

7. Whenever you cut a release to Production, archive the release and any executable builds. Although you can get the source straight from version control using the Tag, it's more convenient (especially for admins!) to have the releases archived in a folder outside of version control.

8. Make sure you have some form of release notes database (or spreadsheet) that lists the features/bugs with the release Tag and the date/time of the release.

9. Give developers the freedom to merge files. In most situations, merges are additive and the merges can be completed using tools. Even if the merge becomes complex, it's not a bad thing for developers to manage the issue by themselves via dialog and code review (tip #5).

10. Keep production parameters such as URLs, user names, passords, etc. outside of version control. Files with the production values for these resources should be managed by the Production team. The build process should have mechanisms to load in configuration files with these values.

A couple of things that you can avoid:

a) Don't worry so much about branching scenarios. In my experience, it's better to work out branching and merging branches when you're faced with that specific need.

b) Nightly builds are nice, but may be overkill for most teams. Understand why you need the nightly build and how you'll use it before scripting this out.
continue reading "Top 10 Tips On Version Control for Small Agile Software Teams"
Share

About Isaac Sacolick

Isaac Sacolick is President of StarCIO, a technology leadership company that guides organizations on building digital transformation core competencies. He is the author of Digital Trailblazer and the Amazon bestseller Driving Digital and speaks about agile planning, devops, data science, product management, and other digital transformation best practices. Sacolick is a recognized top social CIO, a digital transformation influencer, and has over 900 articles published at InfoWorld, CIO.com, his blog Social, Agile, and Transformation, and other sites. You can find him sharing new insights @NYIke on Twitter, his Driving Digital Standup YouTube channel, or during the Coffee with Digital Trailblazers.