AnsweredAssumed Answered

Continuous Integration and Delivery with SDK 3.0

Question asked by gluck113 on Sep 18, 2017
Latest reply on Nov 15, 2017 by marktielemans

Like • Show 1 Like1
Comment • 7

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:

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

What do you think:

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

Sources:

No one else has this question

Outcomes

krutik.jayswal Nov 13, 2017 6:59 AM

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

Actions

cesarista @ krutik.jayswal on Nov 13, 2017 5:11 PM

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.

Actions

gluck113 @ krutik.jayswal on Nov 13, 2017 5:24 PM

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?

1 person found this helpful

Actions

krutik.jayswal @ gluck113 on Nov 13, 2017 6:14 PM

yes correct.

Actions

marktielemans Nov 14, 2017 9:00 AM

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.

3 people found this helpful

Actions

gluck113 @ marktielemans on Nov 15, 2017 8:49 PM

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... :-)

Actions

marktielemans @ gluck113 on Nov 15, 2017 10:27 PM

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.

2 people found this helpful

Actions

7 Replies

krutik.jayswal Nov 13, 2017 6:59 AM
Mark Correct
Correct Answer
JAR is Best solution , with jar we can do deployment easily,
Like • Show 0 Likes0
Actions
- cesarista @ krutik.jayswal on Nov 13, 2017 5:11 PM
  Mark Correct
  Correct Answer
  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.
  Like • Show 0 Likes0
  Actions
- gluck113 @ krutik.jayswal on Nov 13, 2017 5:24 PM
  Mark Correct
  Correct Answer
  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?
  1 person found this helpful
  Like • Show 1 Like1
  Actions
  - krutik.jayswal @ gluck113 on Nov 13, 2017 6:14 PM
    Mark Correct
    Correct Answer
    yes correct.
    Like • Show 0 Likes0
    Actions
marktielemans Nov 14, 2017 9:00 AM
Mark Correct
Correct Answer
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.
3 people found this helpful
Like • Show 1 Like1
Actions
- gluck113 @ marktielemans on Nov 15, 2017 8:49 PM
  Mark Correct
  Correct Answer
  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... :-)
  Like • Show 1 Like1
  Actions
  - marktielemans @ gluck113 on Nov 15, 2017 10:27 PM
    Mark Correct
    Correct Answer
    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.
    2 people found this helpful
    Like • Show 1 Like1
    Actions

Continuous Integration and Delivery with SDK 3.0

Outcomes

Related Content

Recommended Content