On 10/14/16, 12:33 PM, "Sean Dague" <s...@dague.net> wrote:
> I kind of wonder if that hints to a better model here instead of the > deployments running services from master. Instead running periodics and > moving forward reference hashes every day if tests pass, and not if they > fail. That would let deployment tools automatically move forward, quite > close to master, but not get tightly coupled into every change. FWIW That’s pretty much what OpenStack-Ansible does for our ‘integrated build’. We have the ‘production style’ deployment pinned to upstream SHA’s which Are updated once every two weeks. This allows us to get on with our own development instead of being disrupted every time something causes a break upstream. We then only have to deal with upstream-related issues when we update SHA pins. However we do also do more focused, slightly less complex builds on a per role (per upstream service) basis which build directly from the upstream branch. These have a broader testing spectrum (more platforms, more backends) and due to the lower level of complexity in the number of components used in the builds they are generally successful unless our own patch is bad. From my own standpoint I think that if production-type build tests (with functional testing) are executed using deployment projects there would need to be: 1. A good track record of the builds succeeding without failures due to circumstances that are specific to the deployment tool project. Ie The builds must be at least as successful as DevStack in its results with as few false negatives as possible. 2. Each project using these tests would need a designated liaison to the deployment project in order to expedite the triage of issues that arise from the tests. The service project person understands the service and the deployment project liaison understands the deployment project. Effectively they should pair up to quickly triage and resolve any check failures that arise. 3. The tests should not just be a deployment test – they should have some level of functional testing too. If this is not the case then all that’s happening is that the deployment tooling is being tested – not the effect of the patch to the service project. J ________________________________ Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail message may contain confidential or privileged information intended for the recipient. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at ab...@rackspace.com and delete the original message. Your cooperation is appreciated. __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
