I'm currently working on applications in Wolftech I.T., and have been working on a lightweight release process.
The historical approach is to initiate a project in a beta folder with access to production filesystem and database resources. While I've migrated the apps I'm working on into a fully isolated development environment, there are still gaps to bridge in deployment.
I'd like to hear how others are addressing software release processes:
- Version control, particularly release tagging/branching
- Continuous Integration, including automated testing (Is anyone using Jenkins for C.I. ?)
- Deployment automation, including database migrations and releasing patches
Some things we've done:
Yes, fetch with hard reset is the right way to go. One of the options for pull makes this easy if you haven't made any local edits:
git pull --rebase
I was referring to rebase --onto for the neutral copy change management so that you can keep a feature branch synced with master until the feature branch is completed.
Got it on the branch syncing. I don't think a reset --hard is equivalent to a pull --rebase; the latter could have an unresolved conflict from history rewriting on the remote or a local commit. Conflicts are uncommon but still potentially there.
Right, I was lumping history differences into "edits". That's what I get for typing too fast, ha!
This is a big deal to us, so we are working on changing up our process. Here is what we do now, and then where we are planning to go very soon.
What we do now...
This has worked for us for a few years, but it has become a huge pain lately as we are doing a lot more deployments. It (usually) takes 2 of us to do all of this stuff in a timely manner, and there is a lot of areas for screwing up. So, I'm currently working on moving to something more automated.
Where we are going...
As far as testing, we have unit tests written for a good chunk of our core framework, but we need to do better about it for the rest of our code. All our unit tests would be integrated as part of our jenkins environment.
We are in the infancy of our migration to our new way of doing things, but I will report back once we have things setup.
Garrison was the one working on the environment deployment, and I think he was using Puppet, so I don't really know about Vagrant.
Vagrant is more about making isolated, reproducible development environments using VirtualBox. Puppet/chef or even shell scripts can be used to provision the environments. We were thinking it could be a good tool for setting up environments for part-timers and work studies, and as a workaround for those who otherwise prefer the DOS Windows platform.
As far as symlinks, we're likely working on very different versions of webservers if you are on Engineering's webservers. They are a much different animal than the rest of the webservers from OIT.
Using symlinks for deployment staging and cutover was one of the first things I looked at (and it certainly doesn't work on our servers). I didn't want to believe it, but I do understand the motivation for the prohibition.