Here are remaining steps from previous post about publication:
Step 5: Everybody on Version Control System (VCS)
I do not know how many times I have drawn this diagram but it’s been a few! Here’s the best picture I got from it:
Our VCS in Subversion (SVN).
Golden Rule: No FTP access to project files (they must be in SVN to be published).
This illustrates how we work with VCS. All developers commit their code to SVN and update regularly to make sure their code is merged and still works with the latest updates.
Golden Rule: Always update your copy and test before committing your code.
Staging and live servers are a unidirectional working copy from SVN.
Golden Rule: Never commit anything from staging or the live servers
All changes are tested locally by the developer, committed to SVN and then staging is updated. Testing on the staging environment is required before the task is finished.
Always keep the publication log (see Step 7: Publish wisely) updated when publishing. This will also keeps track of dependancies between cases.
This publication process helps:
- developers to integrate their code with more confidence
- the code to be more stable
- code changes to become available to other developers sooner
- speed up debugging as developers can identify bugs on the development stage
- reverting to a previous revision
- no more FTPing files (up 2 folder, upload, down a folder, upload down a folder, upload…)
A quick login using putty and a “svn update <files>” is enough to get the server copy updated.
How do we get the file list? Easy! Subversion (SVN) is linked to Fogbugz. When we commit a code change we enter the case number in the description field. This will show the file list committed in Fogbugz. Brilliant!
When the project manager tells us to “update case 10923” we look at the list of files, the publication log (to see if there are any dependencies) and update those files on the server.
Golden rule: Always include your case number when committing code
We keep the database and it’s structural changes in SVN too. If a developer makes structural database changes they need to commit those changes to SVN.
This will point out potential bugs between developers code: when they update their working copy they see the database changes to apply to their db. These bugs are identified sooner in the process.
When publishing a case, if there are any database changes, these need to be executed in the appropriate db (staging or live).
What about if we need to run debugging on the staging/live server? We do it! But we make sure:
- we FTP the file(s) to the local working copy
- revert staging/live file(s) to what they were
- commit from the local working copy
- update staging/live, respecting the unidirectional update to the servers
Step 6: Keep the staging environment the same as the live environment
I could write a book about pitfalls between different servers.
Different operating systems, HTTP server versions, server side language versions, database versions, permissions, users, groups, all can change from server to server.
Golden rule: it’s essential to have the same environment setup on both servers
- To keep the publication smooth from staging to live servers
- Saving debug time when publishing to live (and then the code needs to be tested again on the staging server)
Step 7: Publish wisely
In most of our scenarios the staging server is used as the test server until there is a stable enough version to be released to the client. Then the test server becomes the staging server.
This way the project managers and testers have access to the application while under development.
Publication to the servers is, in most of our projects, done in the same order that the code is committed to SVN. Great! Saves us the hassle to have to branch and manage complex version control.
That is not possible for all clients, so when you have multiple developers working in a project you need to know the dependencies between revisions (example: revision 10923 cannot be published if revision 10914 is not published), which revisions are updated on the staging server and which revisions are updated on the live server.
We tried to find a way to centralize this information but we couldn’t find the required reporting capabilities in a single interface, so we have created our own: a publication log.
What do we need? To know what revisions have been updated to the staging server, to the liver server, to know dependencies between revisions, if there is any tagging or any database updates for that revision.
What fields to we need to have an overview of where the code it? Here’s one of our publication logs:
Our “Publication Log” is maintained by developers:
- when they commit code the update the log
- each time code is updated on the staging or live servers
Extremely valuable if the developer responsible for publication is not the one that coded the changes.
Conclusion: Keep it real – adapt!
One of the great things about NixonMcInnes is the team’s capability to support constant changes on the procedures. Since I’ve started I have made amazing progress on the way we produce applications.
Massive improvements have helped us to be more efficient, detect issues earlier to save debugging time later, and establish better processes to keep the project on track and in budget.
But the most attractive one is where we want to make sure everybody is happy. If someone detects an area where we can improve, they raise it and we address it immediately. And the team supports the decision.
This is done on a project by project basis.
Golden rule: make people happy