On Thu, Nov 21, 2013 at 6:45 AM, Adam Spiers <aspi...@suse.com> wrote:
> Darrel O'Pry (darrel.o...@gmail.com) wrote: > > > I hear a lot of knee jerk throw everything out and start over > undertones. I > > don't that that is a wise idea as it loses history. One of the things I > > love about git is history. Also being an agile developer I focus on > > continuous improvement and rarely like to start things over. > > Exactly Darrel! I understand where the instinct for "let's start > afresh" comes from, but really it's only sweeping ugly stuff under the > carpet. And it's not just git history we'd risk losing - it's issue > history, wiki history ... > It also doesn't address the workflow issues that created the current state of things... It's more important to address a possible cause rather than a symptom. <snip> > > > 2) On boarding new developers. > <snip> > > Beyond that we go our of our way to make development across platforms > easy. > > We typically use virtual box and vagrant as a starting point to normalize > > everyone's development environment and share the git checkout with the > > vagrant. This way everyone is building on the same build environment. > We > > typically share the git checkout from the VM host to the build VM. The > > build, run, test within the VM. You just expand the number of vagrants > you > > use to test on other platforms. I tend toward veewee if I need to build > and > > track any sort of super custom vagrant base boxes. > > > > Standardising the dev environment is a great idea. There's still some > remaining work to do in order for this to be SUSE-friendly though. > Most SUSE-oriented folk prefer KVM to VirtualBox, and last time I > looked, vagrant's support for kvm / libvirt still needed work. This > would be well worth completing. Secondly, building openSUSE-based > ISOs is still a work in progress (I worked with John on this last > weekend). > This is a situation where I feel the needs of the project to be accessible as a whole, should override the preferences of a few participants. VirtualBox is a free cross platform desktop virtualization environment. It is available to windows, mac, and linux developers. It is accessible for both corporate teams and private hackers. The public shared project should focus on the most accessible development tools possible. Try to cater to kvm, vbox, vmware will just add unnecessary complexity to on boarding a new developer. It's totally doable, but it means that new developers have more decisions to make to get started on the project and someone has to spend time planning, testing, and maintain support for multiple virtual box providers. It means time will be spent debugging whether the problem is the virtualization layer or crowbar. Time better spent making crowbar more awesome. If the team at SUSE or any other team is really insistent on maintaining another development environment, they should be welcome to fork and manage their own tooling to convert the vboxes to kvm. Alternatively, get involved in the vagrant and veewee communities to streamline the generation and publishing of consistent virtual machines for multiple virtualization providers. Even then tools like veewee don't make much sense in a developer's workflow. I've tried fitting things like veewee into developer workflows with the idea of letting everyone build images from preseed and kickstart... Too much time is spent building images and drinking coffee for simple package additions. The approach our teams use is to build minimal vboxes using veewee. We mostly use debian/ubuntu so we switch the tasksel from standard/server to minimal to reduce the OS footprint in the VMs. We also remove ruby, chef, and puppet to avoid conflicts with whatever we'll be installing. We store the veewee definitions in our code repositories so they're tracked with code, but we don't require developers to build the vboxes. We build and publish them to a private website where our team can access them. We don't do any configuration via veewee except setting up ssh and public key access (necessary for vagrant). We also use private keypairs in lieu of the public vagrant keys for our private projects. All of the dev environment configuration is handled by vagrant provisioning shell scripts.. typically config.vm.provision "shell", path: "bootstrap.sh". There is of course a need to expand on this to build a dev environment for a project like crowbar that needs multiple vm for building and needs to setup a rather complex testing environment with mutiple vms. The nice thing is you can also ship a testing environment with vagrant and the same boxes. This makes it possible to vagrant up dev vagrant up ubuntu12.10-admin vagrant up bare-node1 vagrant up bare-node2 vagrant up bare-node3 vagrant up bare-node4 Which could all be wrapped up in a grunt, make, rake, shell script task... There could even have a grunt watcher kicking of environment re-builds and test locally on commit. It would probably be wise to expand testing to KVM and other virtualization providers and testing stacks... When we've helped clients implement deployment and testing of other opensource projects in private environments with more rigorous testing and QA requirements, We've created a separate internal deployment repository that includes the upstream code as a sub-module and provides the project or implementation specific continuous deployment pipeline around the existing public project tooling. Feel free to reach out directly if anyone wants to implement this stuff. I'm glad to help if people are interested in the community can agree on a direction, but my time to contribute actual code to open source projects is limited by my own consulting practice. We've also been unfortunately lax in building model repositories as starting points, and I'm unable to share examples of our client work. I do have an interest in testing out tooling and workflows in lots of different development environments and settings. Crowbar is a pretty complex case from a continuous deployment perspective and the virtual development to bare metal deployment is a an important use case to work with. > 3) Maintenance > > > > We use jenkins extensively to review our pull requests. We do a number of > > smoke tests including linting to enfoce code style, fxcop/sniffing/etc to > > look for common code mistakes, code coverage. We lean heavily on peer > > review of pull requests. Our team is distributed and we don't always have > > the luxury of pairing, instead we do a code review with each pull request > > that includes a developer on the project and a developer from another > > project. It serves to cross train, and have someone less familiar with > the > > project who will not take the knowledge one develops writing and working > on > > the code for granted. > > +1. Of course Crowbar doesn't use Jenkins yet, but it probably could > in the future if we reduced the number of git repos and wanted to > switch to it (I'm not religious either way - github is good enough for > our code reviews IMO). We actually use GitHub for everything. Jenkins is pretty easy to integrate with GitHub and setup to update your pull requests with testing... We run a Jenkins server per GitHub repository in the cloud and run our build agents on physical hardware with virtual box and vagrant available so we can do all of our unit testing inside the same development environment as the developers without having to do a lot of customization in our build farm to support projects.
_______________________________________________ Crowbar mailing list Crowbar@dell.com https://lists.us.dell.com/mailman/listinfo/crowbar For more information: http://crowbar.github.com/
