2.1. Creating a Team Development Environment

It might not be immediately clear how you can use the Yocto Project in a team development environment, or how to scale it for a large team of developers. One of the strengths of the Yocto Project is that it is extremely flexible. Thus, you can adapt it to many different use cases and scenarios. However, this flexibility could cause difficulties if you are trying to create a working setup that scales across a large team.

To help you understand how to set up this type of environment, this section presents a procedure that gives you information that can help you get the results you want. The procedure is high-level and presents some of the project's most successful experiences, practices, solutions, and available technologies that have proved to work well in the past. Keep in mind, the procedure here is a starting point. You can build off these steps and customize the procedure to fit any particular working environment and set of practices.

  1. Determine Who is Going to be Developing: You need to understand who is going to be doing anything related to the Yocto Project and determine their roles. Making this determination is essential to completing steps two and three, which are to get your equipment together and set up your development environment's hardware topology.

    The following roles exist:

    • Application Developer: This type of developer does application level work on top of an existing software stack.

    • Core System Developer: This type of developer works on the contents of the operating system image itself.

    • Build Engineer: This type of developer manages Autobuilders and releases. Not all environments need a Build Engineer.

    • Test Engineer: This type of developer creates and manages automated tests that are used to ensure all application and core system development meets desired quality standards.

  2. Gather the Hardware: Based on the size and make-up of the team, get the hardware together. Ideally, any development, build, or test engineer uses a system that runs a supported Linux distribution. These systems, in general, should be high performance (e.g. dual, six-core Xeons with 24 Gbytes of RAM and plenty of disk space). You can help ensure efficiency by having any machines used for testing or that run Autobuilders be as high performance as possible.

  3. Understand the Hardware Topology of the Environment: Once you understand the hardware involved and the make-up of the team, you can understand the hardware topology of the development environment. You can get a visual idea of the machines and their roles across the development environment.

  4. Use Git as Your Source Control Manager (SCM): Keeping your Metadata (i.e. recipes, configuration files, classes, and so forth) and any software you are developing under the control of an SCM system that is compatible with the OpenEmbedded build system is advisable. Of the SCMs BitBake supports, the Yocto Project team strongly recommends using Git. Git is a distributed system that is easy to backup, allows you to work remotely, and then connects back to the infrastructure.

    Note

    For information about BitBake, see the BitBake User Manual.

    It is relatively easy to set up Git services and create infrastructure like http://git.yoctoproject.org, which is based on server software called gitolite with cgit being used to generate the web interface that lets you view the repositories. The gitolite software identifies users using SSH keys and allows branch-based access controls to repositories that you can control as little or as much as necessary.

    Note

    The setup of these services is beyond the scope of this manual. However, sites such as the following exist that describe how to perform setup:

  5. Set up the Application Development Machines: As mentioned earlier, application developers are creating applications on top of existing software stacks. Following are some best practices for setting up machines used for application development:

    • Use a pre-built toolchain that contains the software stack itself. Then, develop the application code on top of the stack. This method works well for small numbers of relatively isolated applications.

    • When possible, use the Yocto Project plug-in for the Eclipse™ IDE and SDK development practices. For more information, see the Yocto Project Application Development and the Extensible Software Development Kit (eSDK) manual.

    • Keep your cross-development toolchains updated. You can do this through provisioning either as new toolchain downloads or as updates through a package update mechanism using opkg to provide updates to an existing toolchain. The exact mechanics of how and when to do this depend on local policy.

    • Use multiple toolchains installed locally into different locations to allow development across versions.

  6. Set up the Core Development Machines: As mentioned earlier, core developers work on the contents of the operating system itself. Following are some best practices for setting up machines used for developing images:

    • Have the OpenEmbedded build system available on the developer workstations so developers can run their own builds and directly rebuild the software stack.

    • Keep the core system unchanged as much as possible and do your work in layers on top of the core system. Doing so gives you a greater level of portability when upgrading to new versions of the core system or Board Support Packages (BSPs).

    • Share layers amongst the developers of a particular project and contain the policy configuration that defines the project.

  7. Set up an Autobuilder: Autobuilders are often the core of the development environment. It is here that changes from individual developers are brought together and centrally tested. Based on this automated build and test environment, subsequent decisions about releases can be made. Autobuilders also allow for "continuous integration" style testing of software components and regression identification and tracking.

    See "Yocto Project Autobuilder" for more information and links to buildbot. The Yocto Project team has found this implementation works well in this role. A public example of this is the Yocto Project Autobuilders, which the Yocto Project team uses to test the overall health of the project.

    The features of this system are:

    • Highlights when commits break the build.

    • Populates an sstate cache from which developers can pull rather than requiring local builds.

    • Allows commit hook triggers, which trigger builds when commits are made.

    • Allows triggering of automated image booting and testing under the QuickEMUlator (QEMU).

    • Supports incremental build testing and from-scratch builds.

    • Shares output that allows developer testing and historical regression investigation.

    • Creates output that can be used for releases.

    • Allows scheduling of builds so that resources can be used efficiently.

  8. Set up Test Machines: Use a small number of shared, high performance systems for testing purposes. Developers can use these systems for wider, more extensive testing while they continue to develop locally using their primary development system.

  9. Document Policies and Change Flow: The Yocto Project uses a hierarchical structure and a pull model. Scripts exist to create and send pull requests (i.e. create-pull-request and send-pull-request). This model is in line with other open source projects where maintainers are responsible for specific areas of the project and a single maintainer handles the final "top-of-tree" merges.

    Note

    You can also use a more collective push model. The gitolite software supports both the push and pull models quite easily.

    As with any development environment, it is important to document the policy used as well as any main project guidelines so they are understood by everyone. It is also a good idea to have well structured commit messages, which are usually a part of a project's guidelines. Good commit messages are essential when looking back in time and trying to understand why changes were made.

    If you discover that changes are needed to the core layer of the project, it is worth sharing those with the community as soon as possible. Chances are if you have discovered the need for changes, someone else in the community needs them also.

  10. Development Environment Summary: Aside from the previous steps, some best practices exist within the Yocto Project development environment. Consider the following:

    • Use Git as the source control system.

    • Maintain your Metadata in layers that make sense for your situation. See the "The Yocto Project Layer Model" section in the Yocto Project Overview and Concepts Manual and the "Understanding and Creating Layers" section for more information on layers.

    • Separate the project's Metadata and code by using separate Git repositories. See the "Yocto Project Source Repositories" section in the Yocto Project Overview and Concepts Manual for information on these repositories. See the "Locating Yocto Project Source Files" section for information on how to set up local Git repositories for related upstream Yocto Project Git repositories.

    • Set up the directory for the shared state cache (SSTATE_DIR) where it makes sense. For example, set up the sstate cache on a system used by developers in the same organization and share the same source directories on their machines.

    • Set up an Autobuilder and have it populate the sstate cache and source directories.

    • The Yocto Project community encourages you to send patches to the project to fix bugs or add features. If you do submit patches, follow the project commit guidelines for writing good commit messages. See the "Submitting a Change to the Yocto Project" section.

    • Send changes to the core sooner than later as others are likely to run into the same issues. For some guidance on mailing lists to use, see the list in the "Submitting a Change to the Yocto Project" section. For a description of the available mailing lists, see the "Mailing Lists" section in the Yocto Project Reference Manual.