[FOLIO-572] Create continuous integration demo Created: 24/Apr/17  Updated: 12/Nov/18  Resolved: 26/Jun/17

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Niels Erik Nielsen Assignee: John Malconian
Resolution: Done Votes: 0
Labels: sprint13, sprint14
Remaining Estimate: Not Specified
Time Spent: 7 hours, 45 minutes
Original estimate: Not Specified

Issue links:
Blocks
is blocked by FOLIO-636 Update stripes-docker role in folio-a... Closed
is blocked by FOLIO-632 Refactor folio-ansible for stable/tes... Closed
Sprint:

 Description   

We relatively recently moved to using regular module releases for the public demo.

That means, new developments are not shown until the modules are properly released.

There's an ongoing discussion as to how often or how organized releases should happen - like once per development cycle in a coordinated fashion, or, whenever developers find that they completed new functionality in a given module.

So, for now it would be nice to have a CI demo as well, where progress can be verified, regardless of what release habits different teams or developers may apply.

A CI demo might regularly run into compatibility problems - that's why we left that model, I guess - but that can also happen to the demo based on releases (as is the case at the time of writing).



 Comments   
Comment by Cate Boerema (Inactive) [ 25/Apr/17 ]

Thanks, guys. This issue is really high priority for me, as I want to be able to verify stories when they are completed.

Comment by John Malconian [ 28/Apr/17 ]

I've created a 'development demo' Jenkin's build that consists of a "known" FOLIO backend configuration with the front-end using the HEAD of master so the build is triggered every time there is a commit to master branch of any of the UI/Stripes modules. t's at https://folio-uidev.aws.indexdata.com - However, there are a couple of issues with it.

  • The job can run several times of day and building the backend portion takes way too long each time. Rather than building the backend each time, performance can be improved by building an EC2 AMI (image) of the backend and versioning these backend images similar to the blackbox images. Will open separate issue for this.
  • The job frequently fails because new commits are typically breaking something else. I suppose that's the nature of CI testing.
Comment by Niels Erik Nielsen [ 29/Apr/17 ]

Awesome, John.

Oh, right, I see the challenge with hyper-frequent UI commits and the back-end build being so heavy now.

Finally, as annoying as it may seem, the breaking is still a side benefit IMO.

Thanks!

Comment by Jakub Skoczen [ 23/May/17 ]

As discussed on the call: John&Wayne to work on a Gdoc about issues around the demo system which will be then discussed and specific issues will get created.

Comment by John Malconian [ 26/Jun/17 ]

I think this can be closed now that folio-testing and folio-stable have been implemented.

Generated at Thu Feb 08 23:06:47 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.