So this is my first job as a Software Engineer, and I have some questions about how some of our software works so I can better visualize the setup. Basically I'm wondering how code promotion and source control "tie in" to one another. So my company makes an ASP-based web application; call it WidgetX. We have separate servers called Testing and Production that each have their own version of the web app, each used for obvious purposes. The code promotion system (whether you like it or not!) looks something like this: (1) Developer pulls down code into his/her sandbox (working copy) and makes changes/additions (2) All modifications are committed to a development branch in source control (3) A code review takes place, where many things happen, including the developer demonstrating that the new code works on his machine (3) Code is pushed (by a buildmaster) to the testing environment, where QA tests the sh*t out of it to see it is working properly (4) Business review takes place (5) Buildmaster pushes code to Production (live webserver) I am new to source control, and get the basics, but am wondering how things are probably set up here, and what it means when our buildmaster "pushes" code from one environment to the next. If I had to guess, I would say that we have a traditionally-set-up SVN repository with a trunk/, branches/ and tags folder. The development branch is located at branches/dev/. So when I commit new/changed files to the dev/ folder, and the buildmaster goes to promote/push them to Testing, what is he doing?? Does that mean he is just physically copying (or FTPing) the newly-committed files to the codebase residing on the Testing server? How would we ever know for sure what versions we have on Testing and in Production? These are things that I feel I am expected to already know ad don't feel comfortable asking my boss, especially being the new guy.

In my capacity doing this kind of work:

What push to testing usually involved:
1) Used source control functionality to mark a set of changes to promote to test environments. This usually is code that has been dev-tested, builds in our build system, and passes unit tests. This would be something like a baseline in ClearCase, or a set of changes in P4.
2) Integrate changes from #1 into a release branch of the code.
3) Ran build against the release branch. The build result should be some sort of deployable package. .zip, MSI, something like that.
4) Transfer the built package to a testing environment and installed.



That's what we call pushing to test. "Code Push" usually means that they build the code and install the resulting binaries in some environment.

Quote:Original post by Telastyn
1. You should get comfortable asking dumb questions. Dumb questions are better than dumb mistakes. Hopefully your workplace is good enough to foster open communication, but...

Seconded. Everyone asks dumb questions at some point...

Actually, lets scratch that. Everyone asks ignorant questions at some point. Ignorance is only a bad thing, though, if you do not attempt to correct it when necessary, which is what you're trying to do. No-one starts out knowing everything.

The answers to your questions will vary widely based on where you work. You should just ask.

Where I work, our testing server has an actual subversion working copy of the project, checked out from the trunk. It has some local modifications, such as some configuration options that are identical to the production environment.

When release time comes, all branches are tested and then merged into the trunk. The test server's working copy is then updated from subversion and tested thoroughly. At that point, the actual deployment to production looks something like this:

1. The updated code is rsync'ed directly from the test server's webroot directory to a private directory on the (remote) production server, excluding the .svn directories.


2. The production server globally locks the main database and most web access (to prevent errors from half-updated code).


3. The production server rsync's code from that private directory into its own webroot, and updates the DB schema if needed.


4. The access locks are released.

Your organization may or may not do things completely differently.

To give you an idea of how widely this process can vary, here's how a deployment of LucidChart looks:

1. I launch a new EC2 instance from my saved web-server image.


2. I take a snapshot of the old web server's storage drive and attach a copy to the new server.


3. I rsync the latest code onto the new server, and manually update the DB schema as needed.


4. I thoroughly test the new version on the new server.


5. I reassign the IP address of the old server to the new one.


6. If everything works well, I decommission the old server.

This is pretty dramatically different from my previous example--I actually provision a new server on every major release. The point is, your organization probably uses yet another scheme.