Your website will typically go through what is known as a "Development, Stage, Live" process. That means there are three key places your website will exist:
- Development, where a team of developers can push all their code together in one place and make sure it all works as a whole;
- Stage, where developers can push a copy of your website for you to review and approve before making it available to the wider world; and
- Live, your actual, customer facing website.
The three "environments", as we call them, described above are usually all in a different state. Development will have the very latest code, not fully tested, hot off the presses from the development team. Stage will have the latest tested code from Code Enigma, waiting for you to test it yourself and confirm you agree it is ready to be made public, so Stage is usually similar to Live but not quite the same. It's a little "ahead" of Live in the workflow. Live is the last version of the website you agreed was good to go and is currently being presented to your customers. Their visibility to people is generally set up as follows:
Next it is important to understand where we keep your website. A Drupal website is made up of three parts, the database (which contains your actual content, your articles, blogs, comments, some settings, and so on), the uploaded files (documents you uploaded, photos you added to your content to make it look prettier, and so on) and the code (the actual instructions for the computer, our development work, the Drupal system itself). Ignoring the database and the uploaded files, because they are handled a different way, the third piece (the code) is kept in what we call a Version Control System (or VCS for short). There are many types of VCS out there, the one we prefer to use is called Git.
When we start a new project with you, we make a "repository" for you in Git. You can think of this as like a drawer in a filing cabinet, dedicated to the code we generate while working only on your project. Everything we do will be saved in your repository.
Because we have the three environments (development, stage and live) which, as explained, will have different copies of the code in them at any one time, we also need to save different copies of the code in your repository. To do this we create three "branches" in your repository, which you can visualise as files in your filing cabinet drawer. We call these branches "master", "stage" and "prod". Confusing, but "master" is a default Git branch created automatically and "prod" is short for "production", another way of referring to the live website. The way these branches map to your environments is as follows:
When developers work on your code, they do so on their own personal computers. They take a copy of the master branch in Git to their computer, make the changes they need to make, test everything works OK and finally "push" their changes back to the VCS, Git, so those changes get put into the master branch (that file in the VCS that contains the code for your development environment).
We run a continuous integration system called Jenkins. Continuous integration, in its simplest form, means we automate the process of our developers copying their code to the development environment, by having another computer program, called Jenkins, watch for changes all the time. When it spots a change pushed to the master branch in Git, Jenkins behaves like a puppet master and commands the development machine to go and fetch a new copy of the master branch and make it available in the development environment:
This exact same process happens again for the stage environment, when the team lead for your project decides the code in development is ready for you to test it. He or she will copy the code from the master branch to the stage branch in Git and, just like in the above diagram, Jenkins is constantly watching the stage branch and wlil command the stage machine to take a new copy of the code from the stage branch as soon as there is a change.
Unlike the development environment, this stage environment is available outside of Code Enigma (though it is password protected). You will receive a link, and possibly a username and password, from your project manager so you can login to the stage environment and review our work.
Once you are satisfied with the work in the stage environment and you ask us to put it up on your live website, the team lead will once again copy the code, this time from the stage branch to the prod branch (remembering prod is short of production, and is our way of describing the live environment). This time Jenkins will not trigger automatically. Instead, we will schedule the Jenkins "build" with you for a convenient time, as there is usually a very short period of outage while the build is run. At the time you agree, one of our systems administrators will trigger the build and Jenkins will, as before, command the live server(s) to take a new copy of the latest code, and your changes will be live.
If you ever need additional branches or environments for specific tasks, just raise a ticket with the support and hosting team. Some teams, for example, like to separate the stage environment from one they call "quality assurance", or QA for short, stating QA is for testing and stage is really just the last step before live. Any case might be if you need a space to enter content in because your live site is not quite ready yet, again, no problem, just let us know.