This explanation is in context of EBS package-based project, but it would apply to other types of package-based projects as well.

• Packages are built as result of build workflow execution and can contain all files or selected files from project.

• Package name is optional but it is good idea to use package name for easier identification. All files package will always use auto generated name matching version name.

• Packages built using select files can be rebuilt using "Re-Build Package With Same Files." button on Project activity. This allows for package refinement over course of delivery of the specific feature/fix.

• You can look for specific package using filter button on project activity. This will help you rebuild package easily. Or you can start of Packages screen to rebuild the package as well.

Continuous Integration

Continuous Integration (i.e. schedule build) is now supported when using all files approach as well as package based builds. See below some examples of Project setup and implications on Continuous Integration.

• Project as per Option 1 on Source Control Folder Structure

  • Single project is setup in FlexDeploy with all files of specific custom top.

  • If you would like to perform build and deploy of all files then you will be able to setup CI at project level as well as part of release. In this case you will be relying on SCM branching support to manage code being delivered.

  • If you would like to maintain many packages (select files) for delivery then CI is supported via release.

  • Support in Release

    • You can add this type of project to Release to deploy all files or deploy one or more packages.

    • If you use all files approach in Release, you can add project only once in Release as it contains all files.

    • If you use package (select files) approach, then you can add same project multiple times in Release as different package name.

    • Project package (used with build - select files) files can be defined on the package definition screen, i.e. you can add/remove files from package.

    • At build time, developers will see package name as list of values and can choose to add a new package at that time as well.

• Project as per Option 4 defined on Source Control Folder Structure

  • Using this approach you will setup many projects each containing specific set of files from SCM for specific custom top. You will need to maintain separate folder structure in SCM to achieve as explained in Source Control Folder Structure.

  • Projects setup using this approach are more suitable for all files approach. You can still do select files but as only specific set of files from project but by definition as such projects contain less number of files, it would work fine with all files approach.

  • As always when you use all files approach, you will be relying on SCM branching support to manage code being delivered. CI is supported at project and release level.

  • Support in Release
    
    

    • Release definition is mostly same except some subtle differences as we now have more projects with this setup.

    • You can add project to Release to deploy All Files or deploy one or more packages.

    • If you use all files approach in release, you can add project only once in release as it contains all files. If you use package (select files) approach, then you can add same project multiple times in Release as different package name.

    • Project package (used with build - select files) files can be defined on the package definition screen, i.e. you can add/remove files from package.

    • At build time, developers will see package name as list of values and can choose to add a new package at that time as well.

    • As we are using finer grained projects, it makes sense to use all files approach and avoid having to manage packages.

Build Package Procedures

There are many options available to initiate build packages (select files), but for all options you have access to modify files and/or revisions. For example,

1. Use keywords to find files. If you type ldt in search bar, any files including ldt will appear in the files list.

2. By Revision - this option works well when you have committed new files that you want added to package.

3. Edit and View File Content - these menu options allow for editing details about the file as well as viewing the file content in the browser.

4. Copy to Package and Move to Package - you can easily reuse files from packages by either copying/moving them to an existing package or creating a new package when selecting these options.

Use actions described above to refine your package details.

Open

Adding files to empty package

Open

Viewing non-empty package

Build new package from scratch

This option is to create new package that is not part of Release.

1. Go to the Packages tab in the project screen.

2. Click on the Create button on the right side of screen.

3. In the Create Package popup, enter a package name. Package name can be anything you like, but it can only contains letters, numbers, underscore, dash and dot. Package name can represent specific extension or feature request id or hotfix number.

4. Select the Package Type as User Managed.

5. Click the Save button.

6. This is optional, if you have files that were edited or changed, you can add them in the By Revision screen

7. Search for the names of files and they will appear in the search bar.

8. Select individual files you need and they will be put into the Files to Add basket. You can also click the Add All button to add all of the files from the results list.

9. Click the Save button after selecting all of the files you want.

Now select the bottom Execution tab to the left of the Package Files tab. Click the BUILD button that appears in the middle of the screen.

• Select appropriate values for Environment, Stream.

• The current package will be the only option when creating a Build Request. To use another package, click on the Execution tab in the project’s tool bar.

• Click Submit.

• When build request completes successfully, you have package ready for deployment.

Package build is completed after some time.

Rebuild existing package

Start process by finding the package that you want to rebuild. If it is on the first page it is just easy to locate it, but you may have to use Filter option.

Once you have located package, you can use Rebuild option.

This will bring you back to build request form that is pre-populated with details of existing package.

As described earlier now you can adjust the files and/or revisions for package and click Submit Request. If there are no changes in source control then you can select the Force Build option or click the Force Build button if it prompts you after clicking on Submit. When build request is successful you will have new version of package. Keep in mind that package has version that uniquely identifies it from previous builds of same package.

Build new package for release

In this example, we will be using Release with packages. Let's look at an example of Release where we have few different packages for a project.

Each package has files defined which can be managed by Manage Files link.

Definition of files inside a package can be done when package is built as well.

We will start build process by selecting the ALM-150 package from the Packages tab in our EBS project.

As we are using Release, we will be selecting release for this package build. Note that in this case, package name is drop down of packages configured in Release. Click Submit to finish build of package.

When build completes, we will have new package built and ready for deployment.

As we are using release and pipelines, new snapshot is created and ready for execution on completion of build.

At this point, we only have one package built for this release, so we have only one item in snapshot for release. As other packages are built, snapshot will evolve to contain new versions of packages.

Deployment is also finished as per pipeline that is selected on this release.

In this example, we have manual check for deployment (definition of pipeline is entirely up to you and it is good idea to avoid manual steps). Once manual check is completed, deployment is ready for next environment.

This process will continue as packages are built for first time and built again. FlexDeploy will perform change detection at file level for packages, so if file version was already deployed it will be skipped.

Rebuild existing package for release

This process is same as Rebuild existing package when not using Release, only difference is that you will see Release selected as it was selected in previous build of the release package. As files are defined on package definition in release, you can also use Create Snapshot option for Release or Build new package for release and final result would be same.