Simple Continuous Delivery for Java and Groovy Developer (SCD4J) is an automation platform for configuring and installing your Web IT infrastructure. With just one command you can install clusters and deploy applications in any stage of your software development process. Note that SCD4J is not another option for Puppet or Chef. It is, actually, a simpler option than those tools.
The main advantages of using SCD4J over its competitors are:
- Designed with a very specific purpose in mind
- Small and medium enterprises which have opted in to use Java technologies and Continuous Delivery
- No environment configuration
- No need to install and configure coordinator servers
- No need to install agents on clients
- Small learning curve for Java and Groovy Developers
- Built upon modern and well known Java technologies
- Smooth integration with your existing binary repositories (i.e. Artifactory, Nexus, etc)
- Very simple architectural model
- Use module and files hooks to implement the automation logic
- Developers get closer to sysadmins once they can quickly and easily jump into the infrastructure coding
Infrastructure Automation
After the 2010’s Continuous Delivery boom, too much has been talked about how to automate builds in order to anticipate issues, to assemble higher quality software and to ensure the creation of more reliable applications. However, fewer resources on the internet focus on the infrastructure automation.
It is important to say that one of the main issues I’ve seen during all the time I’ve worked as a Software Consultant is the lack of infrastructure standards (mainly the lack of standards between different stages of the software development process) and the error prone manual configurations performed by sysadmins. Both of these problems are well addressed using an automation infrastructure tool. Unfortunately, current well known solutions are too complex for non programming sysadmins and have a huge learning curve for Java developers. Making this kind of adoption, in rushy companies, somewhat difficult.
That is where SCD4J shines. Its simple architecture and specific purpose design makes it a very good match for pairing the knowledge of sysadmins and Java developers to build your company's Web infrastructure quickly.
SCD4J: creating a new project
To start a new project, first we must create a file called build.gradle, as show in the below example:
plugins {
id "com.datamaio.scd4j" version "0.7.5"
}
scd4j {
install {
modules "my_first_module" // should be any dir into modules dir
config "my_first_config.conf" // should be any properties file into config dir
}
}
|
Then, we may run the task newproject of our build.gradle using the installed gradle build tool.
Note: We need to have Gradle 2.1 (or higher) installed just for the first run. After that, SCD4J will automatically install a Gradle wrapper. Please, see Requirements for more details.
Once the execution has finished we will have the following directory structure created:
build.gradle
config/
my_first_config.conf
modules/
my_first_module/
Module.hook
gradlew
gradlew.bat
gradle/...
|
The config dir contains the configuration files. In our case the my_first_config.conf file (i.e. a Java properties file) in which we must put all the variables that will be used by our modules.
The modules dir contains a new module called my_first_module. This is the place where we will implement our automation. Note that the newproject task also created a file called Module.hook, which we are going to talk a little bit more later in this article.
Finally, we can see a gradle directory and gradlew and gradlew.bat files. Those are the gradle wrapper and, from now one, you can pack this project and run it in any machine without needing to install gradle.
SCD4J: basics
Similarly to any other infrastructure automation tool you can think about SCD4J as a “smart copy tool”. In which we should add files using the full path of the target environment. For example, suppose we would like to install a file called standalone.xml into the directory /opt/wildfly/standalone/configuration, then we should simply add this file in our my_first_module as shown in the below example:
build.gradle
config/
my_first_config.conf
modules/
my_first_module/
/opt/wildfly/standalone/configuration/standalone.xml
...
|
Running again our project, we can notice that SCD4J has simply copied our file to the right folder. But, in real situations, we want to install slightly different standalone.xml files depending on the environment we are running on. For example, we don’t want to mess with our production database. So, if we are installing the testing environment we need to set a given database URL and password, similarly, if we are installing a development environment we need to set another URL and another password. In order accomplish this we must put those two variable in the my_first_config.conf file and tell SCD4J that this file is a template. For that, we just need append .tmpl at the end of the file name.
build.gradle
config/
my_first_config.conf
modules/
my_first_module/
/opt/wildfly/standalone/configuration/standalone.xml.tmpl
...
|
This way, SCD4J understands that this file will need to be modified during runtime and then we can use one of the existing template options (Groovy Template is the default) to resolve the logic you would like to implement.
It is important to say that for each environment we run our project on we must provide different config files. In order to understand how to do that, take a look at packaging and distribution session of our documentation
Ok... But what about more complex installations?!? Lets say we would like to dynamically generate http port number based on the server and environment we are running on. For those kind of logic, SCD4J offers .hook files.
build.gradle
config/
my_first_config.conf
modules/
my_first_module/
/opt/wildfly/standalone/configuration/standalone.xml.tmpl
/opt/wildfly/standalone/configuration/standalone.xml.tmpl.hook
...
|
As we can see in the above example, we need to create a file with exactly the same name of the original one appending .hook at end. Note that this file is a groovy script in which you can define pre and post implementations. For example:
pre {
// write here the code to execute before the file installation.
def httpPort = dynamicallyBuildHttpPort()
set(“port”, httpPort) // The port variable will be accessible in the post and in the .tmpl file
}
post {
// write here the code to execute after the file installation.
// usually changes file permission, changes file owner, rename it, etc
} |
The same way we can define a hook for a file, we can also define a hook for a module. For that, we need to create a file named as Module.hook in my_first_module dir. It is important to say that the pre definition must return a constant CONTINUE or ABORT. If nothing is returned, CONTINUE is assumed (in <FileName>.hook the constant SKIP_FILE is also allowed). Take the bellow code as an example:
pre{
// put here your pre module installation logic
if( isLinux() ) {
return CONTINUE
}
return ABORT
}
post{
// put here your post module installation logic
}
|
The above example is saying that the module will be executed only on Linux boxes. If we run this module against any other operational system, the installation will be aborted.
It is important to say that SCD4J provides many helpful functions which can be used in the Module.hook and any <FileName>.hook. Those functions allow us to install packages, change file permissions, start/stop a service, run OS specific commands, and so one. To have a complete understanding of which helpers we can use into hooks, take a look at ModuleHook and FileHook public APIs, respectively.
Conclusion
Before finish this short introduction to SCD4J we would like to highlight the core benefiting of using it to install and configure your Web infrastructure:
- Manage IT risks in a simple and efficient way
- Repeatability
- People's time is precious, so use it for smarter tasks
- Spread delivery knowledge
- Infrastructure fully documented
- Documentation will never get out of date
We strongly suggest you to take a look at the project documentation and examples. There you will find more complex options and examples (such as the installation of a wildfly cluster). So that you can quickly learn how to implement real world infrastructure automation.
Thanks for the interest of making the software delivery somewhat more professional. Hope you enjoy our tool.
Sincerely, SCD4J Team
Short Story
Some years ago I was called to help a big company to improve their software quality. Shortly I discovery that the main problem was not the software itself but the process to develop and delivery it. These issues led them to a lot of difficulties to put new versions in production. That situation has generated a real war between IT and Development teams, which, of course, tried to blame on each other. It took me some years to convince those managers to make sysadmins and developers work all together. Recently, more than one year have passed, I accidentally met one of the integration guys who told me that the last time they had an issue in production was before using our tools. That is one of the reasons why I choose to rewrite and publish it as a free software. Maybe other companies may get such benefits from it.
