To have a better understanding of how changes to the code move through the, get committed and finally deployed to the system running in production, here you can learn what is what in the platform we use to develop customer projects.
In a general way, when working on a project you will find your assignments in the issue tracker (JIRA), you will have working instances of the projects in a personal development environment (personal container), you will pull/push the code from/to Git repositories (Stash), and you will see whether your code builds the project successfully or not by checking the continuous integration server (Bamboo).
JIRA is the tracker system we use in Sourcefabric to create and organize issues, plan and build our products and implement customer projects. In our platform, you can find JIRA at http://dev.sourcefabric.org/
Logging your work
JIRA is also the place where you should log your work: the amount of hours you spend working on your assignments. This is particularly important for project implementations.
A personal container is a Linux Container (a.k.a. LXC) system, set up to provide an individual development environment for developers when working on project implementations.
The usage of a personal container removes the hassle for the developer of setting up local instances every time she/he is joining a project. The developer though has always the option of running the development environment locally in her/his personal computer but setting up a project instance to be able to work on it is her/his entire responsibility, and this is often a very time-consuming task. On the other hand, using a personal container allows the developer to focus on the deliverable right away as a working development environment for the project is pushed to her/his container.
Multiple project instances can be deployed to a single personal container. Putting it into different words, if you are a developer and you participate of different projects, the platform will deploy for you working instances of all those to your personal container and you will be able to start working on the code right away. Even better, instances of the same project will be created for you automatically whenever you create a new branch to work on a new feature, improvement or bug-fix.
Stash is the Git Repository Management system used in Sourcefabric to control the source code for customer projects that usually require private repositories. You can find Stash at http://stash.sourcefabric.org/
Stash is like having a GitHub or Bitbucket system, installed on our own servers. Why? Simple, Stash allows us to have as many private repositories as we need and at the same time provides full integration with JIRA, Confluence and Bamboo. If you know how to work with GitHub or Bitbucket, using Stash will be just as easy.
Most importantly, Stash provides the platform that support our development work-flow for customer implementations. No code gets merged into the Git repositories without going through Stash. Collaborative work, communication, code reviews, all that and more is possible thanks to Stash.
Solutions which are of general interest and aim to be released under an open-source license (e.g. themes, plugins, modules, etc) should not be developed in Stash, you should rather use the public organization for the product in GitHub https://github.com/<product>/.
Bamboo is the tool used as Continuous Integration (CI) and Continuous Delivery (CD) platform for customer project implementations. You can find Bamboo in our platform at http://bamboo.sourcefabric.org/
Bamboo can be seen as a notification system on project builds. Once a project is setup in Bamboo, Bamboo tries to build it every time a change to the code is submitted, as a result Bamboo informs whether the build was successful or not. It is a great tool to support developers and QA on automatically and quickly finding issues in the code.
Not necessarily every project has a plan setup in Bamboo for Continuous Integration. The Team Leader will communicate the development team whether Bamboo CI is used in the project or not.
In Sourcefabric, software for customer projects is developed in a four tier model: Development, Integration, Pre-Live and Live. Let's see what each of these environments represents.
(a.k.a. personal environment)
The code from Stash repositories together with the instances of projects deployed to a personal container constitute the Development environment. The place where the code gets first written or modified by the developer.
A personal development environment is entirely owned by the developer, in consequence all what happens here is her/his responsibility. The developer can try here radical changes to the code as those will not affect the rest of the development team.
It is in this environment also where the work done by the developer gets reviewed for the first time.
For in-progress code:
For fully finished work:
To submit code changes to the Integration environment the developer must open a Pull Request to the corresponding repository/branch in Stash.
Inviting more people to your development environment to review partial work is not mandatory, it is entirely up to you. However, inviting others is advised. Getting feedback early in the process of development only saves you time and allows you to improve the quality of the code and the implementation before finally pushing it to the next environment.
The Integration environment is a common place where all developers commit their code changes. The major goal here is to combine and validate the work of the entire development team so that it can be tested before promoting it to the Pre-Live environment.
Developers are the owners of this environment. QA has no incidence in this environment at least it is required as it may happen in some exceptional cases.
(a.k.a. pre-production or staging environment)
Pre-Live is an environment that mimics the Production environment. It is the last check-in point before deploying the new version of the code to Production.
This environment is owned by QA and it is where the final iteration of testing happens. The QA team thoroughly test the code and validates all changes made and, in general, the integrity of the system. Any found issue is reported back to the development team.
Once the QA team accepts and declares the code as "Ok to release", the Lead Developer runs the deployment to Production by merging the code into the corresponding Stash repository/branch.
This is the environment facing the end-users, nothing happens here, the system must work trouble-free, that's it.
The structure of repositories is project-dependant. We try to make this as generic as possible so that getting the code is a no-brainer and you don't need to spend time asking around what to do every time you join a project. Here you will find some guidelines that should work most of the times.
The repositories here refer to the ones used on customer-specific development, for example: a Newscoop theme, a Newscoop plugin, a Booktype module, etc. and it is assumed the project is built on top of an official released version of a product (e.g. Airtime, Booktype, Newscoop, Superdesk.)
Every Newscoop-based customer implementation project has a corresponding Stash project where Git repositories can be found. In a typical Newscoop project you can usually find the following type of repositories:
where theme- is a prefix used to clearly indicate the repository holds code for a theme, and <ThemeName> is the name given to the theme, always using capital cases as in the examples below.
e.g. theme-ZentralAnchorage, theme-YemenLightBlue
Plugins: Repositories which hold all the files that conform a Newscoop plugin. One repository holds one and only one plugin. These repositories are named using the following convention:
where plugin- is a prefix used to clearly indicate the repository holds code for a plugin, and <PluginName> is the name given to the plugin, always using capital cases as in the examples below.
e.g. plugin-WorldWeather, plugin-FacebookLogin
Depending on the requirements of the project there may exist other types of repositories. If that is the case, the Developer Leader and Project Manager will accordingly inform the team about it.
In all cases, every repository will have the following basic branching model:
master env/prelive env/live
master is the main development branch, while env/live and env/prelive represent environment branches:
Other branches may exist in the repository, in those cases the conventions for the branching model presented here apply.
You, as a developer, should always base your work on the version of the code contained in the master branch.
You are John Doe and you are working on a project named foobar. You were assigned to develop two new features ft-1234 and ft-4321. This is how your personal development environment should look like:
Remember to invite others (developers, QA stuff, stakeholders) to check out your feature instances so that they can provide valuable feedback early in the process.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.