As we have already mentioned in a previous post, Clinker implements a conceptual model for a software development ecosystem made with a group of tools living together to let developers work without interferences due to unconfortable or inexistent integrations between these tools.
The building blocks of this conceptual model are stick together by a single-sign on (SSO) service. On top of all we need a number of deployment environments where our applications will be running. This illustration tries to give a glimpse of this conceptual model.
This model is the result of years of experience and each block is included in Clinker as a gear of a well-integrated machinery. You can make all those parts working isolated but one of the values added by our team is the smooth integration achieved with all those pieces, like the SSO simplifying the maintenance of users for each of the parts in the ecosystem.
But this article is not intended to explain each of these blocks. We are going to focus on the importance of the deployment environments which are drawn out of the box on purpose.
What are deployment environments for?
You need to deploy your application to make it available for users. That’s the production environment. But you can also have other kind of deployment environments depending on your needs, like automated functional testing, exploratory testing, stress testing, commercial demos, pre-production, etc.
Exactly the same way we can plug an external repository in Clinker (like a github instance or some internal repository behind our corporate walls), we can also use a deployment environment located out of the same infrastructure where Clinker is installed.
Clinker does not include any deployment environment. It goes beyond our scope. Why? Simply because we want to do one thing and do it very well. If we had tried to include all the different kind of deployment environments any team could need, probably Clinker won’t be as mature as it is now. We prefer to give our clients the freedom to decide where to put their deployment environments and focus on giving the sysadmin the best tools to manage their teams’ ecosystems.
If your runtime is Java, then Jelastic is a very good choice, mainly because their awesome simplicity to set up and put an environment ready to work.
As you can see in the illustration above, Jenkins is our ultimate responsible to deploy the artifacts in your environments, like Jelastic, so they can be used for the corresponding tasks defined in the continuous integration process, like running tests or even going on production with a certified version of your application.
Jelastic is so simple to set up that we can have very quickly our own environments to verify and validate our artifacts (e.g. a WAR packaged application), to deploy our application and run the testing plans, or run metrics to know about performance, quality assurance, etc.
Not sure yet? Have a look at how easily you can deploy any Java application using maven-plugin-jelastic. Then think that you can include those lines in your own continuous integration plan and save a lot of time deploying your artifacts, always in the right environment, of course.
So, Jelastic is a perfect fit as a deployment environment for your Java applications… much better if you are using Clinker for the rest of your ecosystem. Yay!