09. Best Practices

Always version you project before packing it

As we have discussed in Packaging and Distribution it is super important that you have both package name and version set in the your build.gradle file. This allows a better control of the version being run.

archivesBaseName='MyPackName'
version = 0.1

If you don't set the above properties, SCD4J will use as the package name the name of directory AND unspecified as version number.

Infrastructure as a code

Manage your SCD4J project as you manage any other source code. In other words, commit it on your repository, generate releases and tag it. This ways you gonna have the full history of what has been done in the infrastructure and who has done such changes.

Avoid Feature Branches

It a good practice of Continuous Integration and Continuous Delivery to use one development branch only. This tool was designed for Continuous Delivery, so, please, avoid branching (note that it is totally fine to use release branches). If you think you can not avoid it, I would strongly suggest you to read these:

• Feature toggles: good or bad?
• Is it possible to do Continuous Delivery using branches?
• Continuous Delivery Book

Certainly you will find a good alternative.

Infrastructure fully documented

• Commit the original file version before making any change to it. This make pretty ease to compare versions and understand the differences and reason behind such differences.
• Just appending .del to deleted files. Keeping the original file make it very easy to add it back whenever it is required. The issue here is more related to some source code repositories that do not keep track of deleted files.

Use extensions to resolve dependencies

In SCD4J it is pretty straight forward to resolve and install dependencies. However, In order to avoid mistakes it is important that you always provide the full dependency name, including the file extension (eg. @deb, @rpm, @zip, @ear, @war or @jar). This way you avoid using SCD4J inference (which may change in the future).

Avoid using URL to resolve dependencies

Although the url (..) option is pretty straight forward to resolve dependencies, we strongly recommend to not use it instead you are 100% sure that the link will never be changed and the host will never get down. Otherwise, use it only for example purposes. This way, the person being trained does not need to set up a binary repository (eg. Artifactory or Nexus) for executing an example.