Jump to content
  • Advertisement
Sign in to follow this  
plywood

Questions I'm afraid to ask at work

This topic is 3233 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
First things first. Two things actually.

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...

2. It kinda doesn't matter. Some things will be black boxes, and it's useful as a programmer to accept that and work with it.

On to answers.

Quote:
Original post by plywood
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/.


This is a little unusual. A development branch is usually done on a release by release basis, or inline. I've not seen a place that has a single dev sub-directory for dev-work.

Quote:

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?


At the very least he's taking the produced binaries/markup and pushing them to the server.

He probably needs to also grab content (perhaps from a different repository), and probably grab some configuration data to push to the server.

If your company is smart, he's also tagging the source code in the repository with some build marker (usually what testing cycle you're in, or other project milestone eg: 1.10-QC2). 'Old' code does need to get looked at every once and a while, so that's useful. It also allows fresh installs to go smoothly, even if the dev team commits more code.

In this scenario, it likely unfortunately means copying from the dev sub-directory to a (not public) test or qa directory and re-commit.

Share this post


Link to post
Share on other sites
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,

Hear, hear.
IOW, "amen to that."
AKA "QFT."

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rycross
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.

Yes you should be able to ask questions unless you somehow already claimed to have the knowledge and are try to hide it?
I'm sure you boss will be alot happier if you actually do your job correctly than screw things up because you were afraid to ask.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!