Development Workflow
DevStack enables you to leverage advantages of cloud developing with as little change to your workflow as possible. This means that you can continue using your favourite tools (e.g. IDEs, log management software) that you are used to.
Of course there are some differences in how certain elements of the development workflow happen. Below, you'll find a guide on how you can develop remotely.
Creating and Deploying an CDE
To develop remotely, you'll need to have a Cloud Development Environment (CDE) first.
Create
You can create one or many CDEs. Each of them is an instance of a specified build. E.g. you can create an CDE for each branch that you use for development so they are ready and built for whenever you need them.
CDE creation can be done in the self service portal, completely autonomously.
Configure
When you create an CDE, you can define its properties with predefined templates. After loading a template, you can modify the configuration if needed. Note that some properties might not be customisable, depending on your setup of DevStack. Get in touch with your DevStack administrator if you need more templates or extra customisation options.
Deploy
Once you're done with the configuration, simply click on "deploy" in the self service portal. After a short time, the CDE shows up in the list of CDEs and is automatically started.
The license is based on CDE runtime hours, meaning that an CDE only consumes the license allowance once it's running. You can have multiple deployed CDEs that are ready to be started, without consuming any of your allowance.
Starting an CDE
Once you have an CDE, you can start it and connect to it. Depending on the method of source code synchronisation, you might need an additional initial setup when you first start an CDE.
Start
CDEs that are ready to be started are listed in the self service portal. Simply click on "start" to do so. After a short time the status of the CDE gets updated and you're ready to connect to it.
Initial Setup at First Start
If this is the first time that you start an CDE that is synchronised via file and folder synchronisation, read this section. If this is not the first time or the CDE is synchronised via file and folder mounting or via pure SSH, you can skip this section.
Here's how the initial setup works:
- Locate the CDE in the self service portal,
- expand the section that describes the initial setup,
- execute the commands in the instructions.
That's it! Now the local folder is set up and synced to the CDE. You're ready to start developing.
Developing with an CDE
Once your CDE is up and running, you can develop from your local machine.
Work on the Source Code
You can work on the source code locally. If your DevStack instance is set up to use pure SSH source code synchronisation, this can only be done in an SSH capable IDE.
Work with Logs
DevStack let's you access and work with logs in different ways. Read more about it here.
Branch switching
Switching between branches can be done differently with an CDE than in a local development workflow. You can create an CDE for every branch that you need. They can wait in the background until you need them and once you want to work on a branch, simply start and switch to the corresponding CDE. Since the CDE is already built, this reduces the time needed to work on another branch.
Version Control
Using git or another version control system works in the same way as with a local development workflow. You can commit, revert, etc. as usual.
From the user perspective this looks the same for all methods of source code synchronisation. Here's how it's done under the hood for the different methods:
-
for File and Folder Synchronisation:
This methods keeps version control in the local repository.
The source code repository is cloned at the first deploy to a repository on the CDE. Then the same repository is initialised locally. Local changes are synchronised to the CDE, however, git commands are only executed in the local repository (e.g. commit in the local repository, push to origin). This works, because even though the CDE lags behind in commit history, it's contents are kept synchronised with the local repository.
-
for File and Folder Mounting and Pure SSH:
This methods keeps version control on the CDE.
The source code repository is cloned at the first deploy to a repository on the CDE. Changes are made and git commands are executed directly on the CDE, through locally mounted folders or through an SSH capable IDE (e.g. commit in the repository on the CDE, push to origin).
Stopping an CDE
If you're done working with an CDE you can stop it in the self service portal. A stopped CDE does not use your licence allowance. Stopping an CDE does not delete it and you can simply start it again to pick up work where you left it.
CDEs can be configured to automatically stop after an idle time or outside of business hours.
Deleting an CDE
If you don't need an CDE and won't need it in the future, it is best practice to delete it in the self service portal. Deploying fresh CDEs is fast and ensures, that your CDE is created with up-to-date templates.
Before you delete an CDE, make sure to commit and push your work. Also save any other data that you want to keep (important logs, test results etc.)
Deleting an CDE deletes all data on it as well.