|
Developer Community |
|
Loading...
|
|
Development ProcessThe ForgeRock Development Process is built on agile practices and adheres to the ForgeRock Development Principles. This process is used for all community projects in the ForgeRock I3 Open Platform.Overview of the Development ProcessThere are a few guiding principles for general development process. Strive to keep trunk in a buildable state. This means that if there are significant changes that will affect multiple files or areas of the product, they should be developed in isolation (discrete branch) until you are comfortable that they will not break the build. Once they are complete, they can then be merged into the trunk. Be aware of compatibility - backward and forward. Any API level changes should be brought to the band. Dont re-invent the wheel! The products use many libraries, and implement many useful utility methods. Re-use them. We will use version control. Currently the projects use SubVersion, however this is subject to change at any time. Do not build assumptions around the specific version control system in use into the project.
The Development ContextTestingThe amount of testing for each bug fix or RFE should be determined by the dev and QA team. The general guideline is that all unit tests should be run for any fix.How to commitIn order to submit changes to the OpenAM source tree, one has to be at least a Fan. This means that they have to have a login into forgerock.org. There are 3 different kinds of code submissions that we need to address:
Simple Patches to trunkSimple patches to the main trunk, are patches that affect less than 100 lines of code, and affect less than 5 physical files. This is expected to be the majority of fixes for issues raised in Jira. Most fixes are going to be 3 or 4 lines. After review the patch is committed directly to the trunk.Complex Patches to trunkComplex patches to the main trunk, are patches that affect more than 100 lines of code, affect more than 5 physical files or is being developed by more than one developer. This kind of patch has to be developed in its own branch, allowing the developers to commit changes and test changes. Any contributor can request a branch for their development. Branches are expected to be transient and to only be valid for the length of the development of that feature or fix. Once the development work is completed, it will be merged back into the trunk.ExtensionsExtensions are meant for longer term projects, or sub-projects that are not supported by Forgerock. Any Contributor can request an extension, over which they have control. The Band will determine if this is a reasonable sub-project and will not unreasonably withhold approval. The extension owner is able to determine who will have developer access and how they will handle commits. At some point, an extension might be mature enough to be brought into the supported software, at which time, it will become part of the main OpenAM project and subject to the normal submission process.Submitting code changesThe way that you contribute code changes depends on what kind of user you are. A fan always has to submit changes as a "review then commit". A roadie or rockstar is able to submit changes using either "review then commit" OR "commit then review".Review then CommitThe development process for a simple patch is:
The development process for a complex patch is:
Commit then ReviewThe Commit then Review process is meant to be used by Roadies or Rockstars, when making simple changes that they are confident will not adversely affect main source. It is always a good idea to have someone else review any changes before committing them and “review then commit” is the suggested method for any non-trivial changes. The development process for a simple patch is:
Bug fixes/minor RFE'sA bug fix or a very minor request for enhancement (RFE) should not have a big overhead. The prerequisite is that the resulting functionality in the product is not significantly altered by the change. This eliminates a lot of the work in considering the impact of larger changes. The development process for a bug fix or minor RFE is as follows:
Note that branches in subversion are "cheap" and do not create a copy of code until the files are changed. |