Continuous Integration and Delivery with SDK 3.0

cancel
Showing results for 
Search instead for 
Did you mean: 
gluck113
Established Member

Continuous Integration and Delivery with SDK 3.0

Hello Everybody, 

Lately I've been wondering about Continuous Integration and Delivery best practices for an Alfresco project. Unfortunately, I found mainly dated presentation (SDK 1.0). I think that with the SDK 3.0 things change a little bit:-)

 

I personally think that the best solution is to deliver the final .war file. This guarantees no further manipulation (apply_amps.sh), no generation error and easier rollback.

 

But in any case, here are all the possibilities I thought:

  1. Generate amp file and deliver it
  2. Generate .jar file and deliver it
  3. In the CI take the generated amp from apply it to a war and deliver that war
  4. run the "alfresco:run" command with "generate-wars-only" profile and get the resulting war. (Not a big fan)

What do you think:

  1. Do you see other possibilities?
  2. How do you manage your CI/CD on your Alfresco projects?

Sources:

  1. Make it possible to generate WARs without alfresco:run in SDK 3.0 · Issue #420 · Alfresco/alfresco-s... 
  2. GitHub - toonconvents/alfresco-sdk: The Alfresco SDK based on Apache Maven, includes support for rap... 
  3. Enabling Test-Driven, Rapid Dev, & Continuous Delivery of Alfresco Apps | Alfresco Summit is becomin... 
  4. https://www.alfresco.com/cmis/browser?id=71b66e10-deeb-40fd-92f2-bb57cdb3b9de%3B1.0 
7 Replies
krutik_jayswal
Senior Member II

Re: Continuous Integration and Delivery with SDK 3.0

JAR is Best solution , with jar we can do deployment easily,

cesarista
Advanced

Re: Continuous Integration and Delivery with SDK 3.0

Hi:

With SDK 3.0 projects in recent Alfresco versions, yes (option 2). If no SDK 3.0 projects, and thinking in a clustered enviroment, I prefer to generate the war and change it in every node.

Regards.

--C.

gluck113
Established Member

Re: Continuous Integration and Delivery with SDK 3.0

I agree that when you can manage your extension with only one jar it's the best solution.

But if you need to involve amps (dependencies on others amps and need a specific loading order) you need to deliver the wars don't you think?

krutik_jayswal
Senior Member II

Re: Continuous Integration and Delivery with SDK 3.0

yes correct.

marktielemans
Active Member II

Re: Continuous Integration and Delivery with SDK 3.0

Delivering prepackaged war files is never a good solution for production to me, simply because we manage a lot of installations where ours may not be the only customizations present, or where we simply need more freedom to switch out modules. Handling only complete war files takes away any flexibility you have, and your distributions will in this way be tied to a specific version or even installation of Alfresco. An amp built for Alfresco 5.1 might work on Alfresco 5.2- a war file most certainly will not. Not to mention that you get to move bigger files around.

Instead we much prefer to build amps (if we have 3rd party dependencies) or module jars (if not), and use a script that keeps the out of the box war files and applies amps to a new copy of those every time it is executed (instead of applying amps to the same war files incrementally over and over again). I believe Loftux uses a similar approach in their Alfresco installation for Ubuntu set of scripts.

Whatever is best for you really depends on your use-case. If you have a development and CI process streamlined for delivery to one Alfresco product, I can imagine you'd use prepackaged war files, and in theory you could go even further in this case and include your app server and its' configuration in your CI automation. It's a lot different when delivering varying combinations of addons to a wide variety of Alfresco implementations however, like we do. We depend strongly on the modularity that amps and jars give us.

Disposable application server approach

Most of the stuff in an Alfresco installation is pretty disposable; only the installation/client's specific data is important per instance. For our hosted Alfresco customers, we have a Cloudstack based system in place that allows us to throw out and recreate a customer's Alfresco VM and re-attach their data (contentstore/DB/indexes/config overrides). The recreated VM can have different binaries, for example a version upgrade of Alfresco or addons, taken directly from our Nexus. Be they amps, or war files, this approach allows for easy enough CI as long as it's okay that the environment is unavailable for a couple minutes. So with this approach of a disposable appserver, war or amp really doesn't matter very much.

Last note: we're very hesitant to use the module jars, as we've found them to be pretty buggy so far.

gluck113
Established Member

Re: Continuous Integration and Delivery with SDK 3.0

Hi Mark

Thanks for your thorough answer. It's true I hadn't thought about this use-case of multiple addons and parties. In our situation we have full control on the entire chain. We also at one customer deliver the entire tomcat installation by CD (a little overkill but was interesting to set up :-))

I also like your Cloudstack approach, I should look more into that but a lot of our customer manage their infrastructure on premise and will be quite reluctant to such an approach. But who knows what the futur reserves... :-)

marktielemans
Active Member II

Re: Continuous Integration and Delivery with SDK 3.0

In a full control situation I can definitely see the merit of producing your own war file!

Lots of our customers are government, so they have been and still are in some cases especially hesitant to move away from onprem installations. We find that transparency about security and providing private clouds with VPN tunnels goes a long way in this respect.

Personally, I believe that ECM, like other software markets, will ultimately be consumed mostly as a service. That seems quite inline with Alfresco's Amazon partnership.