Using Multiple Environments to Improve Your Development Workflow
In today's modern business environment, it is imperative for product development teams to maintain an optimal workflow if they hope to remain relevant in the competitive market. Having a well-tuned workflow not only keeps a team productive, but it also helps them deliver software that is reliable and in a timely manner. Implementing DevOps has become an important requirement for any team maintaining a large project or working on multiple projects. DevOps provides the process and the tools that keep teams working effectively and efficiently.
No matter what your DevOps process looks like and the various tools you use, a recommended practice for any significant software development project is the use of multiple environments. Using multiple environments ensures that your software is rigorously tested before it is deployed and made available to users.
An example setup could have development, staging and production environments:
- Development: The development environment would be the first line of defense against bugs. Here, developers deploy their code and test any newly implemented features. Any bugs found are dealt with before re-deploying for further testing. The process is iterated until the code is ready for the next stage of testing.
- Staging: Once developers are satisfied with their code and consider it fairly stable, it is then deployed to the staging environment for further testing. This is where Quality Assurance (QA) is performed. Testers access the staging servers and ensure that the application works as it should. They run test cases to detect bugs and run performance tests to find areas that could be improved. Any bugs or enhancements are reported back to the developers and the process is repeated until the code passes the staging phase.
- Production: Once the code has been thoroughly tested, it is then pushed to production where it is made available to end-users.
The above environment setup is just an example and shows the three common environments for software projects. Your setup may vary according to your project and team's needs. You could have more or fewer environments set up, for instance, some people prefer to have a Pre-production environment to further test the code before the final deployment to Production, and others maintain separate Staging and QA environments where developers perform further tests (e.g. integration tests) in the Staging environment and the QA environment is exclusively used for quality assurance testing.
If you've read this far, Version Control is obviously an issue for you. However, if you need to update more than one server, automation makes sense. This is exactly what we offer with DeployBot. DeployBot integrates perfectly with the most popular tech. You can find an ever growing collection of beginners’ guides on our website.
Laravel, Digital Ocean, Ruby on Rails, Docker, Craft CMS, Ghost CMS, Google Web Starter Kit, Grunt or Gulp, Slack, Python, Heroku and many more.
Learn how to get started with DeployBot here.
Advantages of Using Multiple Environments
As mentioned, one of the main reasons for maintaining multiple environments in your Software Development Life Cycle is to ensure that the final version of the product that gets deployed to users is as bug-free as possible. Other than this, there are some other advantages that using multiple environments offers that not only improves a team's overall workflow, but also helps them meet their business goals:
- Using multiple environments keeps a team productive: Having multiple environments enables a team to work on parallel development efforts. If there are several people working on the app, using a different environment for each group of people helps keep the team productive. You can, for instance, have different DEV environments (one for general unit testing, another for integration testing) and several QA environments (one for detailed QA testing, another for high-level business testing by non-technical users and another for performance testing). With this setup, different groups of testers won't have to wait on each other to do their work. A developer can pass code that they are done with to QA and continue working on and testing other code without having to wait for QA to perform their tests and free up the environment. Having multiple environments also prevents lags in the Software Development Life Cycle that might be caused by processes that take up a lot of resources. For instance, running performance tests usually involves simulating and processing huge volumes of test data. This usually takes a huge hit on the machine's processing power and takes a lot of time to complete. If the process is isolated to a separate Performance testing environment, other testers won't be impacted by the hold-up.
- Having multiple environments reduces or eliminates downtime and thus saves the company from loss of revenue: In today's connected world, where news can spread worldwide in a matter of seconds, protecting your company brand has become more imperative than ever. Having a product that faces downtime or that doesn't work as it should could quickly lose you customers. Thoroughly testing software through multiple environments allows you to deliver a product to your users that is just as reliable and dependable as your company. If the software directly deals with the exchange of money, errors in the code could also lead to losses. A few years back, we saw the very quick bankruptcy of Knight Capital Group, an American global financial services firm, that deployed code to production that caused errors that lost them $460 million in less than an hour. Testing code in an environment that closely resembles the production environment could reveal potential problems that might arise if code is deployed to production.
- Maintaining multiple environments provides better security: To protect the integrity of your production data, you should limit access to it. Team members should have clearly defined roles and access rights to different parts of the system. Having multiple environments makes this possible. If you have separate development and production environments, it prevents developers from accidentally messing with or deleting production data. It also prevents sensitive information (e.g. passwords and credit card information) from being made available to people who shouldn't have access to it. A while back, Uber pushed code to Github that contained passwords for their live environment allowing anyone who wanted to, to download their customer details. If their developers worked entirely in a dev environment using dev data, then the dev keys released on Github would have been harmless. This shows the poor decision of performing dev in the production environment.
- Using multiple environments saves time and helps in getting the product to the market faster: Getting your product to market quickly can give you a First-mover advantage that could greatly impact your bottom line. Using multiple environments when developing software saves time as no one has to wait on another person for shared resources. Running multiple tests at the same time, rather than one at a time, results in all tests getting completed in a fraction of the time it would have taken otherwise. Other than helping launch a product as quickly as possible, using multiple environments also allows you to quickly react to user feedback and modify the product accordingly. You could, for instance, have some environments dedicated to working on long-term, multi-month features while others are dedicated to short-term bug fixes and improvements. Not having different systems in place for long-term and short-term initiatives will leave you in a situation where you can't quickly fix bugs identified in the production system or implement features requested by your users, leaving you with very disgruntled customers.
- Using multiple environments promotes innovation: When you are working with multiple environments, your team is free to experiment on environments that are especially dedicated for this. Since there is no fear of messing with the live code, the team can use a separate environment to test out ideas and even deploy the code to a server where it can be made available to some test users who can give feedback on it, which the team can use to decide if they should implement the changes on the main codebase.
Using DeployBot to Help Manage Your Environments
DeployBot can help you easily set up and manage your development environments. First, you connect your git repositories to DeployBot and add users that can view the repositories and run deployments. It supports Github, Bitbucket and any other hosted git repositories with HTTPS or SSH URLs, like Beanstalk, GitLab or self-hosted repositories.
After adding a repository, you can then set up your environment. You can have multiple environments to a single repository. You can associate a specific branch of your repository to a particular environment and set the environment's Deployment Mode to either Manual or Automatic. When set to automatic, the code will be deployed to the server(s) once a commit is made to the branch associated with the environment. We recommend using automatic deploys for all your environments except for the production one. We believe Production deployments should be manual as having a human involved not only ensures that production deployments don't run at inappropriate times, but it also guards against adverse fallouts that might occur if deployment doesn't go as planned. If something goes wrong with deployment or the code causes bugs once deployed, the person doing the deployment can quickly do damage control and rollback the changes to minimize the damage of the faulty deployment.
After setting up an environment, you can then add a server to it. You can have multiple servers within an environment. With a server connected, your code will now be ready for deployment. DeployBot supports deployments to DigitalOcean, Shopify, Heroku, AWS Elastic Beanstalk, AWS S3, Rackspace Cloud Files and all Linux based servers. It can also deploy anywhere else with SFTP, FTP, Shell, and Build servers. If you have multiple servers set up, DeployBot can deploy code to all of them and run any required scripts on all the servers by itself. You can specify commands for each server and choose when they should be executed - before or after deployments.
To manage your environments, servers and deployments, you can either use the web dashboard or the DeployBot API. With the API, you can integrate your deployments with the other DevOps tools you use.
Advantages of Using DeployBot to Manage Your Environments
- DeployBot offers an easy to use user interface that makes it easy to set up, observe and manage your development environments: The DeployBot Dashboard offers a single place where you can manage your deployments. You can connect it to your preferred version control service, set up users that will have administrative control over the deployment process, organize servers into groups (environments) and set configurations for each server and/or group, monitor each deployment and quickly rollback changes in case of bugs. Imagine doing all this manually in the Terminal. Not only would it waste a lot of time, but the whole process would be error-prone. With DeployBot, you can set up a consistent system of shipping code.
- DeployBot automates a lot of the operations needed in managing multiple environments: Working on large projects usually means deploying the same code to several servers. This can be anywhere from two servers to hundreds of servers across the world. Doing this manually would take a lot of effort. With DeployBot, you can organize your servers into environments and set configurations for each server and environment that will determine how each deployment is run. After the initial set up, your developers won't have to worry about deployment. They only have to commit code to the right branch and DeployBot will take care of building the code (it will fetch dependencies, compile code and compress files) and deploying it to the right server(s). This takes a lot of cognitive load off your developers leaving them free to focus on what they are building.
- DeployBot can help mitigate against adverse effects caused by errors: DeployBot has several measures in place to protect your operation from being affected greatly by bugs and errors. First, DeployBot keeps logs during and after all deployments that show the order of commands run as well as other information. In case of any errors, the logs can be used for troubleshooting to identify the point of failure. Second, DeployBot enables you to set up notifications that can be used to keep your team abreast of what's happening with your deployments. In case of errors, the team will be notified promptly, enabling them to deal with the error as quickly as possible. Third, DeployBot enables you to use Atomic deployments for your code. With atomic deployments, if anything goes wrong during a deployment, the whole operation will be discarded leaving the previously deployed code as is. In this way, there will never be any downtimes caused by deploy errors. Lastly, if you do happen to ship buggy code, you can quickly rollback to a previous stable state in a matter of seconds.
- With DeployBot, you can easily scale up (or down) your operation: Adding an environment to a repository or a server to an environment takes a few minutes to configure, so you can quickly scale up your resources. Each environment has a Settings page that you can use to change configurations anytime during the development process.
The maturity of a team’s Software Development Life Cycle (SDLC) directly impacts their ability to deliver reliable software in a timely manner. The tools and process you use could either aid or hinder your development efforts. Having the right tools and a sound DevOps system in place greatly helps in maximizing your company's productivity and profitability. DeployBot is one such tool. It makes the deployment process seamless, leaving your developers to focus on more important tasks: creating great products.
DeployBot is one such tool. It makes the deployment process seamless and works with almost every tech you wish - like Laravel, Digital Ocean, Ruby on Rails, Docker, Craft CMS, Ghost CMS, Google Web Starter Kit, Grunt or Gulp, Slack, Python or Heroku for which we have an ever growing collection of beginners’ guides.
