Setup `staging` flow

[query-string]

At the moment all approved fixes and improvements go directly to production so QA will actually have to review them after deployment which is not clever approach for many reasons. My proposal is:

– Establish staging branch where changes from approved PRs should go – All changes merged with staging will be deployed to sepcontent.s3-website-us-east-1.amazonaws.com and this bucket should be considered as the staging one – Once in awhile (I'd propose simultaneously with our main two-weeks release cycle) staging branch should be merged with master and applied changes delivered to prod.

Additionally, we will have to develop a process of synchronizing Contentful spaces (mostly content models. but from time to time data also might be needed). For the beginning, we could go with manual models synchronization (with a strong agreement that if content model changes in production Contenful space it must be immediately changed in staging space and vice versa). But in future, we have to consider involving some tooling for automatic spaces synchronization.

@dvdbng @skatkov @FanaHOVA would love to hear your thoughts

[FanaHOVA]

– Once in awhile (I'd propose simultaneously with our main two-weeks release cycle) staging branch should be merged with master and applied changes delivered to prod.

I don't like this approach, simply because we don't have enough tasks. I agree that a staging environment might be good to setup, but putting ourselves in a 2 weeks cycle seems counterproductive. This app is really small and requires little to no testing since all the heavy logic is taken care of by Contentful, so let's keep things rolling quickly.

Regarding Contentful, I don't see any benefit in having data synchronized. The articles we receive are just texts and images, let's duplicate everything we have now and that's it. The reason why we backup the production database on dev is because of users params, search, campaign params, etc which can break things. If we do major changes to Contentful (like changing structures, etc) we can update manually, but I don't think that'll be a frequent thing.

[query-string]

I don't like this approach, simply because we don't have enough tasks. I agree that a staging environment might be good to setup, but putting ourselves in a 2 weeks cycle seems counterproductive. This app is really small and requires little to no testing since all the heavy logic is taken care of by Contentful, so let's keep things rolling quickly.

Yeah, 2 weeks cycle seems a bit overcomplicated, but I needed some starting point... What would you recommend then? Maybe PR -> review -> staging -> QA -> production?

Regarding Contentful, I don't see any benefit in having data synchronized.

I was mostly concerned not about data itself, but about data structure. Its changes is not frequent thing indeed, but if one start to ignore manual synchronization models discrepancy starts to accrue like a snowball. Although, if we have production/staging delivery process in place it won't be easy to ignore possible distinction...

[skatkov]

Let's discuss it on All hands meeting? I wrote it down in my notes and will bring it up then.

[skatkov]

Promoting this to critical - I talked with Stan about this and his problem could be solve by this too.

steamer [9:44 PM] @alex @skatkov can we have the live pages update more quickly after publishing them from contentful? the preview view isn't always showing what goes live, and having to wait a couple minutes to see if formatting changes took effect is proving to be inefficient and a drag.

skatkov [2:58 PM] @steamer we just need to fix that preview, there is not much we can do in terms of improving publishing speed;-)

steamer [8:46 PM] @skatkov that's a bummer about publishing speed. what's the constraint? even our old system was able to update the live page almost instantly?

skatkov [8:47 PM] @steamer it rebuilds all the website from scratch every update - to build html, css, js files.

[8:47] @steamer you think better preview will not solve your problem?

[8:48] @steamer we plan to improve publishing speed for multiple edits, we need to move to different build tool (that we can get for free).

[8:49] @steamer it will only optimise in case of multiple edits in short amount of time.

[8:49] not the general speed.

[8:50] @steamer because we don’t use any database, update is not so fast.

[8:51] basically contentful is our platform for storing all our articles. (edited)

steamer [9:04 PM] @skatkov if we can get to 100% fidelity between the Preview mode and the live/published page, that would be great/necessary but still doesn't get us all the way there. what's missing is seeing the entire page, including the image and interaction between the text and any other elements like Related Content.

[9:05] @skatkov sounds like there's no way to just rebuild that page from scratch when it's published, instead of the entire site?

skatkov [9:06 PM] @steamer yeah, it does only entire site. we will create another, second instance, for testing. If you want to play around with articles, maybe that would be more helpful?

steamer [9:24 PM] @skatkov kind of like a staging site? if it weren't too much of a pain to build and make sure staging truly mirrors production, that would be helpful.

skatkov [9:33 PM] @steamer there is no way for us to test new features on a content platform without this. so i guess, we have to build it.

[skatkov]

Technical requirements:

• [ ] script to import contentful settings
• [ ] script to export contentful settings
• [ ] automated solution that 'adjusts settings' based on file from tools (changes to contentful should not be done manually, but only with script/definition file)
• [ ] functioning staiging instance

[skatkov]

https://github.com/contentful/contentful-import https://github.com/contentful/contentful-export

[query-string]

@skatkov let's discuss what is meant by the staging instance now to be on the same page ;) When I firstly created this issue I thought that the staging instance could be something more like another set of settings (dedicated Contentful space + separate CI build settings + another bucket) for QA testing needs. But after re-reading your conversation with Stan I can conclude that we probably need a live instance of Middleman synchronized with Contentful so article changes will be immediately displayed there? If this conclusion is correct – does it mean issue #68 is not relevant anymore? Because described solution looks more like preview instance to me...